This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Hydrophilic
Pages: [1] 2 3 ... 49 Next
1
« on: April 12, 2013, 03:15 AM »
There are only two ways that I know. The easy/combatible way is to file-read the directory (open file $). The hard/incompatible way is to sector-read the directory data (U1...). It would be nice if there was a command, like "get file size" but I do not know of any device that has it... not available on 15x1 drives for sure. So in other words, read the directory.
If you are worried about speed of reading directory, I can think of two options. The easy way is to use filename when open directory for reading, $:FILENAME. This will return a listing of only 3 lines: header, the file you want, and blocks free. The file you want line tells you the size and type. With this method, be sure to open directory on secondary address 0.
The hard way is normally only used if you do a lot of file open/close. In this case, read the whole directory and store the info in RAM. Then you don't need to read directory each time you open/close a file. Besides using RAM, other problems with this method is that you have to update the RAM if somebody appends data to a file, writes a new file, or deletes a file... or if user swaps disks... it is a lot of trouble and you need to be desperate or crazy to try it.
2
« on: April 12, 2013, 01:57 AM »
Sorry, 2 different but related topics. I started trying to access CMD HD/FD using burst command intructions set (BCIS) to allow use with CP/M. The CMD devices seem to work fine with the U1 commands, but CP/M only builds the command string with two-digit values. So sectors 100 to 255 would not be accessible (like-wise for track numbers). The CP/M code could be changed, but it would probably be slower as the 8502 would loop over GETIN/$FFCF for 256 times to read the sector data and then return the result to Z80 which would then move that data from $fe00 to wherever it is suppose to go.
CP/M uses the U1 commands only when fast-serial (BCIS) is not available. So I was trying to access the CMD drives with the burst command instruction set. So far it seems okay with FD / 1581 drives, but I still need to fix the HD / 1571 ambiguity (reported $100 byte sector size).
The test program is not CP/M software (makes it much easier to test). It is simple BASIC interface to BCIS / fast-serial routines.
3
« on: March 19, 2013, 06:13 AM »
I think you would have to make your own cable (if there is an existing solution, I would be interested too). Looking at the XA1541, you could use LPT line 17 which is currently wired to drive /RESET and instead use it write /SRQ. This is because they're aren't any other (non-parallel) outputs available, and because in my opinion, a peripheral (i.e., your modern PC acting as slave) should never have the ability to reset the host (i.e., your C128 and all its devices). The unused LPT line 15 can be used to read the /SRQ line.
Of course then you would need to write software to do this. I played around with the concept years ago. It didn't go to well because I was using an old laptop with CPU running at about 100MHz. This was barely fast enough to emulate 1541 in "raw" mode (i.e., no Windows or DOS or Linux running... custom OS). Of course things could be better with a faster PC, but as far as I can tell, every access to the LPT port slows the CPU down to about 1.5MHz ! For normal serial communication, this is not a problem. For soft fast-loaders (JiffyDOS et al) this can be a problem... it depends if the fast-loader requires constant monitoring... Jiffy DOS does not, but some do.
Unfortunately, the fast-serial protocol is one that needs constant monitoring without some hardware assistance. The reason is that fast-serial mode is identified/requested at "random" ... the C128 for example sends an 8-bit fast-serial request a few microseconds BEFORE it activates the attention line. Usually you can use simple polling of ATN because it is held low for about 1000 microseconds... plenty of time to respond with modern devices.
But the fast-serial request is sent before you're notified there is a request!! (The purpose of ATN is to identify a new transaction on the bus). This is a retarded way to implement a bus protocol! I can only guess that CBM did it that way because of a bug in CIA chip. Whenever the fast-serial output is enabled, the last bit that was transmitted (i.e., a random value), is output for a brief period before the new data starts shifting out. If the last output was high, this is no problem, but if it is low it would confuse devices... maybe... that's my theory... better ask Bil Herd about that.
Anyway, the point is because there is no warning, and each bit is transmitted for only 8 micro seconds, you would have to constantly monitor the /SRQ line... or get some help from the hardware. I'm pretty sure at least one of the LPT lines can be configured to trigger an interrupt. If you used that feature on the /SRQ input you wouldn't have to constantly poll the LPT port.
By the way, when I said 100MHz CPU was just barely fast enough in my experiment... it was because I was emulating everything: the floppy's 6502, 2x6522, 6525, 1771, RAM and ROM. If you only want to implement the bus protocol, something simple as 8MHz Atmega micro controller will work.
Edit
I'm not an expert on all the different cables, but from what I can tell the XM1541 cable uses diodes instead of transistors like the XA1541... otherwise the two are basically the same. Another cable that uses diodes is the XE1541, but the /DATA and /RESET lines are swapped.
The original X1541 cable is similar to the XE cable but does not use any diodes or transistors... it uses one line for both input and output to each CBM line. This requires the LPT port be configured in SPP mode. I think the default for modern PCs is ECP or EPP mode, hence the existance of the other cables. I'm not sure if you would have to completely disconnect /RESET and use it in place of /SRQ or if you could use one of the other lines... this cable is potentially dangerous to your PC (or at least the LPT port) due to the direct connections so I haven't tried it.
4
« on: March 12, 2013, 06:45 PM »
Thanks, wte. The CMD FDs report $0400, the 1581 $0200, and the 1571 $0100 ... because the 1571 commands are different than 1581 / FD / HD commands, the program is assuming you have 1571 if it gets report of $0100. Because the CMD HD is reporting $0100 also, that is the problem.
I was hoping the HD would report $0400 like the FDs, so it could be easy test to determine between 1571, 1581, and any CMD. But thanks to your feedback, it seems a different method is needed.
I once heard somebody say to issue UJ command to device then you can read error channel which would be something like 73, 1571 DOS 3.0 ... (or whatever the device). Of course this is a terrible idea, because if the user changed device# then the reset will undo that and result in bus conflict and possible CPU crash (infinite loop). Sometimes you can break out of infinite loop by turning off drive, other times you have to hit STOP+RESTORE... but somebody "forgot" to connect the NMI to the Z80 so the RESTORE key is invisible in CP/M mode.
So here is a new idea. If size is reported $0200, then assume it is 1581. If it is $0400 then assume it is CMD-FD. Otherwise assume it is 1571 or CMD-HD and send command read logical track 0, sector 1. There is no logical track 0, so CMD-HD should report error, but the 1571 does not have concept of logical addressing so it should read a sector from the first track (physical track 0). Well, I'll try it and see what happens.
Also I'm worried that if fast-serial is not supported (for example, because of parallel cable) that CP/M will fail using the standard/slow method (i.e., using KERNAL which could be really fast with parallel cable or really slow with standard hardware or medium speed with JiffyDOS). I see at least two problems...
1. Without fast-serial, CP/M assumes device is 1541 and applies a sector translation table... this incorporates both sector skew/interleave and zone recording (i.e., variable sectors/track). This is obviously wrong for reading 1581, FD, or HD disk image.
2. The routines that build a "standard" (not fast-serial) command string (U1...) only allow 2-digit track and sector numbers. So it should be fine for 1581 disk image, but would fail for any CMD device.
3? Other problems I haven't thought of...
So I will try to get CMD devices working at least with fast-serial. Then if there is a problem with parallel cable or JiffyDOS the problem could be analysed (by comparison with working version).
5
« on: March 10, 2013, 09:34 PM »
Now that I think about it, I half-way agree with you. For a RAM drive you normally just copy a subset of files, and probably won't use the full 16MB. So here is what I've got so far...
Dynamic allocation of Hash Tables for all drives. If you have 1571, 1581, and 512K REU, then free RAM in Bank0 will be more than the final official version (up from 8K to 11.5K).
If you have a 1571, 1581, and 16MB REU then you still have a bit more RAM than before (up from 8K to 10K).
Now I still think a real 16MB HD would need at least 1024 directory entries. This is because the average file size will probably be around 16K, so 1024 entries would be just barely enough to fully use the HD. You would very likely run out of directory space if you enabled timestamps and/or password protection.
With that in mind, a 1571, 16MB HD, and 512K REU should leave the same amount of free RAM as the last official release (8K).
If you are lucky enough to have 1571, 16MB HD, and 16MB REU, then you would end up with less free RAM than before (down from 8K to 6.5K). There's not enough RAM to have 4 16MB units. But you should be able to have 3... I hope that is enough!
Also note this is worse-case scenario. For example, if your REU is only 2MB, or your HD is only 4MB~8MB, then you can use 5 devices (4 HDs and REU) with a few KB to spare.
Let me back-up and say, you can use them with full directory hashing. If you do happen to run out of RAM in Bank0, you can still use your drives, but the last one(s) accessed will operate slower during directory operations.
I've played around with various combinations of 1541 / 1571 / 1581 floppy drives and 512 MB / 2 MB / 16 MB REU. It all seems to work. Except sometimes you can fragment memory such that some will be lost/unavailable if you do things just right... basically this requires switching between two drives with ever-larger capacity... For example, boot with 1541 on drive A, then read 1541 on drive B, then read 1571 on drive A, then read 1571 on drive B, then read 1581 on drive A, then read 1581 on drive B. Do you see the pattern ? This doesn't seem to be a very a common scenario! (You can not change REU size without a reboot)
Although it seems to be doing dynamic hash table allocation correctly for all drive sizes and REU sizes, I can't be fully sure until I get the CMD disks working (still have the problem with logical / physical addressing... and also it seems they won't work at all with parallel cable).
DEMO Attached
You can play around with the work in progress that supports REUs up to 16MB with dynamic hash table allocation for all drives (but it still doesn't work with CMD FD/HD units). I thought a good test of the system would be to have CP/M build itself. Because it worked successfully, I'm confident it is a robust system. Of course this does not mean it is bug-proof !
I could post a bunch of screen shots, but instead ( after having CP/M build itself ) I just issued some informative commands and capture the printer output.
M>dir m:[size
Scanning Directory...
Sorting Directory...
Directory For Drive M: User 0
M: ADDBIOS COM 8k : BNKBDOS3 SPR 16k : BNKBIOS3 SPR 16k
M: BNKBIOS3 SYM 8k : CCP COM 8k : CONF COM 8k
M: CONF HLP 8k : CPM+ SYS 32k : CPM3 LIB 8k
M: CX80 ASM 8k : CX80 REL 8k : CX80 SYM 8k
M: CXDISK ASM 40k : CXDISK REL 8k : CXDISK SYM 8k
M: CXEM ASM 16k : CXEM REL 8k : CXEM SYM 8k
M: CXEQU LIB 24k : CXEXT ASM 16k : CXEXT REL 8k
M: CXEXT SYM 8k : CXINTR ASM 24k : CXINTR REL 8k
M: CXINTR SYM 8k : CXIO ASM 24k : CXIO REL 8k
M: CXIO SYM 8k : CXKEY ASM 16k : CXKEY REL 8k
M: CXKEY SYM 8k : CXKRNL ASM 16k : CXKRNL REL 8k
M: CXKRNL SYM 8k : CXKYCODE ASM 8k : CXKYCODE HEX 8k
M: CXKYCODE SYM 8k : CXPRINTE ASM 8k : CXPRINTE REL 8k
M: CXPRINTE SYM 8k : CXRAMDSK ASM 16k : CXRAMDSK REL 8k
M: CXRAMDSK SYM 8k : CXSCB ASM 8k : CXSCB REL 8k
M: CXSCB SYM 8k : CXVT ASM 24k : CXVT REL 8k
M: CXVT SYM 8k : CZ SUB 8k : DATE COM 8k
M: DIR COM 16k : DUMP COM 8k : ED COM 16k
M: ERASE COM 8k : FAST8502 ASM 24k : FAST8502 HEX 8k
M: FAST8502 SYM 8k : GENCOM COM 16k : GENCPM COM 24k
M: GENCPM DAT 8k : HELP COM 8k : HELP HLP 88k
M: HEXCOM COM 8k : HIST UTL 8k : INITDIR COM 32k
M: LIB COM 8k : LINK COM 16k : LISTER COM 16k
M: M80 COM 24k : MAC COM 16k : MODEBAUD LIB 8k
M: NEWCZ SUB 8k : PIP COM 16k : RENAME COM 8k
M: RESBDOS3 SPR 8k : RMAC COM 16k : SAVE COM 8k
M: SCREEN40 COM 8k : SET COM 16k : SETDEF COM 8k
M: SHOW COM 16k : SID COM 8k : SUBMIT COM 8k
M: TRACE UTL 8k : TURBO COM 32k : TURBO MSG 8k
M: TURBO OVR 8k : TYPE COM 8k : X6502 LIB 8k
M: XREF COM 16k : Z80 LIB 8k : ZSID COM 16k
Total Bytes = 1192k Total Records = 6217 Files Found = 93
Total 1k Blocks = 819 Used/Max Dir Entries For Drive M: 95/ 512
As you can see from the directory listing, the average (allocated) file size is 12.8K... and there is only 512 directory entries available. Thus (13K * 512 = 6.6MB) it is unlikely you would ever fill the REU (which is why hard drives get a bigger directory).
More semi-useless statistics
M>show m:[drive
M: Drive Characteristics
131,072: 128 Byte Record Capacity
16,384: Kilobyte Drive Capacity
512: 32 Byte Directory Entries
0: Checked Directory Entries
512: Records / Directory Entry
64: Records / Block
2: Records / Track
0: Reserved Tracks
256: Bytes / Physical Record
M>show m:
M: RW, Space: 15,176k
6
« on: March 10, 2013, 08:15 PM »
By the way, the CP/M disk image is supposed to be exactly the same format as a normal commodore disk, so you can copy it with any copier (like hack'em)
At the sector level, yes same format. At the file level, completely different format. Be sure you do a full disk copy (quick file copy will fail).
7
« on: March 08, 2013, 04:54 PM »
I don't know any application that allows you to work on Commodore with FD-2000/4000 disks, except the special FD-TOOLS (see first attachment). It lets you make partitions, format, or copy files... not very usefull as disk editor, etc. It seems not reliable in VICE X128... might work in C64 mode, but I never use that  I did make FD-4000 disk for Media Player 128 Gamma, but since then I discovered that it is probably corrupt! I used VICE to make that disk image (File / Attach Disk / 8 (for example)) and you should see option "Create Image" ... I selected D4M and clicked that create button... But like I said, that image turned out to be corrupt!! I think it is a bug in VICE... or somehow I messed it up after creation ? I didn't do anything fancy, so maybe VICE corrupted it after creation? Anyway, using disk commands (i.e., OPEN / PRINT#) or the FD-TOOS, I re-formatted the D4M image. Now it seems to work correctly. I've attached such a "fixed" blank D4M for every one (zipped up, last attachment). ------- More about the VICE bug... if it really is VICE to blame.... Using built-in "CREATE DISK" of VICE, I got directory that shows correct BLOCKS FREE (12736), and it will allow load/save of much data (this is how I create MP128 disk)... BUT when trying to use direct-access commands, for example classic U1 / Block-Read (or new BCIS $04) then you will get an error if you try to read past track 25... For example track 25, sector 255 is okay but track 26 sector 0 will give 66 ILLEGAL BLOCK 26 0. However, after a (re)format of the disk image, it reports again correct BLOCKS FREE (12736) but now you can access 26... up to track 50 sector 255 (this is logical format... physical track 80 sector ??) Of course this is new stuff in VICE 2.4 some bugs are to be expected. Anyway the attached/fixed disk image seems reliable.
8
« on: March 06, 2013, 10:48 PM »
Thanks for the feedback!
I really don't know what the problem with RamLink might be, but it seems that CMD devices do not respond to fast-serial commands when a parallel cable is connected. (Somebody mentioned similar problem with MP128.)
uIEC will not work unless you have fast serial firmware, and then only for 1541/71 disk images (I need to update the firmware for 1581/DNP).
Since I don't have device with parallel cable (or the needed ROMs), I won't be able to fix CP/M for parallel cable... well it might work if CP/M reverts to non-fast-serial commands (presumably the parallel cable via KERNAL). I guess we'll have to see what happens with the final build...
9
« on: March 05, 2013, 11:40 PM »
Wow that was fast! I submitted mine, only to learn that it is very similar to one of their examples, so I doubt it will impress anyone.
10
« on: March 05, 2013, 11:36 PM »
Check the documentation for 64HDD. There should be a way for it to write a D64/D71/81 image to your CBM disk drive. Just unzip your disk image and follow the procedure. If you can't find how to do it in 64HDD manual, you can try StarCommander. In which, case be sure to do a "full disk" or "sector-by-sector" disk copy (the normal/fast disk copy just transfers the CBM files, but CP/M doesn't use CBM file format).
11
« on: March 04, 2013, 09:56 PM »
I started on a real/proper implementation of big drives (both CMD and REU) and quickly ran into memory shortage... worse memory problems than described above or the related post about memory bugs in Juggler 128. (going a bit off topic) The larger drive sizes added a few KB to the system bank which was expected. What I forgot about was Hash tables. In addition to caclulating a checksum for each directory record (i.e., each 128 bytes of directory) which, by the way is a form of hash, CP/M also has the option (enabled for all drives in all official CBM releases) for "real" directory hashing. In this form of hash, each directory entry (32-byte entry) gets a 4-byte hash. So the problems described in Juggler 128 article are minor, compared to this! For example, some of those extended formats add an extra 128 directory entries... this is only a few bytes in the ALV table, and only 128/4 = 32 extra bytes in the CSV table. Both can trash directory in Juggler 128 ... but the "real" directory hash would mean, in this example, an extra 128*4 = 512 bytes. That is a great way to trash the system... and I am really suprised that such a HUGE bug was not discovered after 8 years. Maybe I am looking at Juggler 128 wrong somehow ? (back on topic) The new larger disk sizes, in particular 16MB CMD-HD or REU result in even more memory use than planned in prior posts of this thread. For example, I thought it would be a good idea to have 1024 directory entries for a 16MB drive. That value seems a bit low for the large size, but I thought it would be a good compromise... Well that turns out to be 4KB hash table! And by default all 6 drives get a hash table. And GENCPM / BIOS statically allocate this to all 6 drives (physical A~D, phantom E, and REU M). That results in 24KB for hash tables... or about 8KB more than is available (plus it would be a good idea to leave a few KB free for system utilities). I don't think DRI did a good job with the hash function... it seems to me that a 12-bit hash should be pretty good... might get several false positives, but then you could refine the hash with an extra 4 bits for a nice 16-bit hash... which would cut the memory use in half. Unfortunately, BDOS does all the hashing internally and doesn't allow BIOS a chance to intervene (except indirectly when building with GENCPM). So aside from building a C256 to hold the hash tables in bank 2 or 3, there are really only two options. Reduce the maximum number of directory entries, or reduce the number of drives that use a hashing table. For example, if the maximum directory entries were 512, that would allow hashing for all drives. But I don't think that would be enough for a 16MB unit... especially if you enable timestamping which would cut the number down to 384 (and passwords would cut that down to a mere 192). The other idea would be to selectively enable directory hashing. I was thinking the first 3 drives that are accessed by the user would get directory hashing and the rest (if any) would have to do without. Note without directory hashing, file operations can take a lot longer. So for example, you could boot from a 1571/81... this would be drive A and it would get directory hashing. Then you could PIP files from a big CMD disk (this second drive would get directory hashing, lets say drive B) over to your (big)REU / 1541-Ultimate (this third drive, M, would also get directory hashing). So in this example, drives A, B, and M would operate like before (except they can be much bigger than 1581) ... BUT if you have any other drives, they would be slower (due to no hashing tables). This scheme would be leave about 2.5KB free in Bank 0. Not much. If you used only two drives (for example CMD-HD and REU) then there would be about 10KB free in Bank 0 (which is more than the 8KB available in the "final" May 87 release). What do you guys think? Fewer directory entries, or limited hashing support ? BTW, I tried some compromise between 512 and 1024 directory entries (i.e., 768) but it still used too much RAM to use with all 6 drives. Anyway, instead of waiting for an answer, I decided to just hard-code it with hashing on drives A,B,E (but not C,D,M) to see what would happen. It left 2KB free in Bank 0. Then I tested some non-standard software to see if they would work. Juggler 128 works, and now normal drives can't corrupt memory because the tables are plenty large enough. However, out of some 140 formats, 2 of them require special drivers (one called "Adam" which I can only imagine refers to the Coleco Adam, and the other even more obscure)... these 2 special drivers will not run because they (would) install in the directory hashing buffer area. Another non-standard program is the CONF utility. This modifies all kinds of obscure system data in Bank 0. Everything I tested seemed to work. I also learned about the CONF DRIVE parameters... lets you assign Unit 9 / Drive 1 (for example) to drive B. It seems Von Ertwine had a Commodore 1572 (or 1582) or he wouldn't have wrote this! Well, I couldn't really test that works, but I did test that it didn't crash the system. My favorite non-standard program is the Tron game by Tokra. High res 80 column graphics... works great! I've never seen a 40 column graphics package for CP/M, and it would probably fail because not enough RAM in Bank 0 (assuming it would use Bank 0).
12
« on: March 03, 2013, 09:34 PM »
There is no correct speed in Warp mode. The emulator runs as fast as your hardware will allow. Which is usually much faster than a real machine... so the cursor blinks much faster than a real machine.
There is no way to fix it; Warp mode runs this way by design.
I hear SuperCPU emulation is planned, and this should allow faster execution without Warp mode. Not much you can do until it is released.
13
« on: March 03, 2013, 05:16 PM »
I recently built simple RGBA converter and wanted to test it with VGA monitor, but unfortunately I had the wrong gender HD/DB-15 connector (and I didn't want to splice wires of my VGA monitor). I thought it might work, so glad you can confirm that it does... like you said the 5V levels can't be good.
That's pretty cool you get 480 vertical without interlace. I guess that makes sense because the horizontal is about double rate. 376x480 is also interesting in that you get more vertical than horizontal... kind of like VIC-II interlace. Would be interesting if VGA could handle interlace... 376x960 ?! Would there be enough RAM if it did work ? Turn your monitor sideways, ha ha! (sounds silly, but I've seen an extremely accurate emulation of Pac-Man than actually requires this, but on VIC screen)
I'm glad to hear that enabling attributes didn't reduce chars to 26. ... So it seems like the attributes are "stealing" about 1/10 of the bandwidth. The VDC sure never ceases to suprise me. If I think more about it, normal char mode should be 9 bytes per char (1 text byte, 8 font bytes), and adding attributes would make 10 bytes per character... which is 1/9 more. That's fairly close to 1/10... although it could be coincidence.
Anyway, great work.
14
« on: March 01, 2013, 07:15 PM »
In case you haven't heard, Juggler 128 is a CP/M program that allows your Commodore 128 to read many "foreign" disk formats using a 1571 or 1581 disk drive. "Foreign" means an MFM format disk from another CP/M system. (As an interesting hidden feature, you can format IBM/MS-DOS PC disks, but CP/M can not use them). A discussion about using it, and some links to the software are in this old post. I've used this program on a few occassions, and it seems so useful that surely others have too. In doing research for a BIOS modification to support CMD disks, I decided to have another look at it to be sure the updated CP/M would be compatible. It seems the modification I have planned will actually improve this software. This is because I discovered a few bugs in Juggler 128, and the planned BIOS modifications should fix (most) them. Herne Data Systems lists copyrights of 1988 and 1996 (as I recall) and since then (200x) they have released this utility as freeware. Although this powerful software, that allows access to well over 100 formats, was bound to have some bugs initially, you would think that 8 years later (1996-1988) the bugs would have been discovered and fixed. The documentation notes several formats that may have "issues" (due to hardware constraints) but what I'm talking about are genuine bugs (software blunders). I was (am) concerned about the increased size of the allocation vectors and the directory checksum for the larger CMD disks, so I decided to see if this was a problem that Juggler 128 had to cope with, and if so, how it did it. Bug 1: ALV CP/M maintains a table that DRI calls "allocation vectors" or ALV. This is essentially an inverted BAM. The BAM on (native) Commodore disks holds a 1 bit for every sector that is available... while CP/M's ALV holds a 1 bit for every allocation unit (cluster) that is used (not available). Besides bit-flipping, the main difference is that native CBM disks hold their used/free map data in a dedicated system area (just before the directory), while CP/M dynamically builds its ALV in RAM by scanning the directory. The ALV is a fixed size in bank 0 RAM. I haven't checked older versions, but the "final" May '87 release of CP/M allocates 100 bytes to the ALV of each physical drive (that is A~E, but M is different). (Presumably older versions would have fewer bytes.) This ALV can accomodate 400 clusters. So first I checked if any Juggler 128 formats have more than that. Yes! There is the "Librarian 1581" and "Maxi 1581" formats. I tried these to see how the software increases the table size. It does not! This means using one of these formats will corrupt the following data in RAM... usually the directory checksum (discussed below) for the next drive. So imagine you have 2 drives. Drive B is a normal disk format, but drive A is using "Maxi 1581". This will cause 2 bugs: the ALV of drive A will over-write the directory checksum of drive B (this makes drive B slower because it must re-read the directory more often), and worse, an access to drive B (which updates its directory checksum) will over-write the ending ALV of drive A, which can result in false "disk full" errors if you are lucky, or destroy/cross-link files in the worse case. Bug 2: CSV Although Commodore disk drives can easily detect a disk change (by monitoring the optical "write protect" sensor), it seems that CP/M was designed in case a system could not detect a disk change in hardware. Specifically, it creates a sort of checksum or hash of each "record" in the directory (a CP/M record is just 128 bytes of data on disk... the original sector size of 8 inch disks). DRI refers to this as the "checksum vector" or CSV. In the "final" CP/M release of the C128, the CSV of all physical drives (A~E) is 32 bytes (presumably the same in older versions). The RAM Drive (REU / drive M:) does not use a CSV because you can't (or at least shouldn't) swap REU's while the C128 is powered on. So second I checked if any Juggler 128 formats have more than 32 checked records. Yes! There are several, including "Librarian 1571," "Morrow MD3," and "Zeneith Z-100" formats. I tried these to see how the software increases the table size. It does not! This means using one of these formats will corrupt the following data in RAM... usually the ALV (discussed above) of the same drive. So imagine you have 1 drive using "Librarian 1571". Whenever CP/M updates the directory (for example, file write), it updates the CSV. If the directory has a lot of files, this update will be at the end of CSV which over-flows into the ALV. This will cause a bug in the ALV of the same drive. This can result in false "disk full" errors if you are lucky, or destroy/cross-link files in the worse case. Bug 3: EXM ? CP/M was originally designed to address 16KB per directory entry ("dirent"). Note CP/M files can have multiple directory entries for the same file. Each directory entry was originally referred to as an "extent." Starting with CP/M 2 (I believe) the possibility to use larger cluster sizes meant each dirent could (depending on disk format) refer to more than 16KB. So the DPB of CP/M 2+ (which of course includes our beloved C128) includes a field that DRI calls EXM. This relates to the number of 16KB "extents" that can be referenced in a single "dirent". For example, a 1541 (or 1571 single-sided) standard CP/M format has an extent mask (EXM) of 0 because each dirent can only reference 16KB. A double-sided 1571 standard CP/M format has an EXM of 1 because a single dirent can refernce 32KB of data. A final example is a 1581 standard CP/M format which has an EXM of 0 because one dirent can only refer to 16KB of data (note a 1581 has fewer clusters per dirent because a 1581 has MANY more clusters than a 1571). Sorry if those examples confused you... the EXM has been troublesome to me too (see other posts I made regarding CP/M updates for CMD drives where I wrote "?" or "99% sure"). The point is, after reviewing DRI documentation, the BIOS source code, and using a debugger with CP/M, it now seems pretty clear that the "extent mask" must be 0 if a single dirent refers to 16KB, or 1 if it refers to 32KB (and I believe 3 if 64KB, 7 if 128KB, or 15 if 256KB... remains to be seen). Assuming this 0/1 corresponds to 16/32 KB per dirent, there are many formats of Juggler 128 that break this rule. I don't have any of those "foreign" disk formats to test this theory so I can't prove that it is wrong. Assuming that Juggler 128 is wrong in this regard, it may be because the bug would never be discovered unless a file was greater than 32KB. I don't know about you folks, but the vast majority of my CP/M files are under 16KB, and I don't think I have any that are larger than 32KB. (BTW, CP/M files can in theory be 32MB, but to be "practical" 16MB is the limit). Conclusion So there are at least 2, likely 3, different types of bugs present in Juggler 128. The modified BIOS that I've planed will increase the size of both ALV and CSV of all drives (both physical and REU). This increased size should prevent the first two bugs listed above from ever occuring (an improvement in my opinion). However, assuming Bug 3 is real, the planned update can not magically fix it. Just letting everyone know now so I don't get messages about how I broke Juggler 128
15
« on: March 01, 2013, 04:07 PM »
Wow, that's pretty cool, direct to VGA. It looks like you get 52 chars / 416 horizontal resolution. I can't really count the vertical, but it looks quite a bit more than 30 rows. That's neet you get more than 25 rows / 200 rasters without interlace... well I assume it is not interlace from your description, and because the faster Horizontal rate means more time remaing to draw more rasters.
Great work. Along with 8x1 color mode, I guess this makes you a VDC master. I wonder how fast the VDC can be over-clocked ? Like if you used a 12MHz crystal instead of 8MHz could somebody get 640 horizontal resoultion (or just fry their VDC) ? Would the V-RAM and bus interface work if the VDC didn't burn up ? Like any great discovery, it brings up more questions!
Edit
Looking at your image again, it seems to be about 50 rows... so maybe it is interlace ?
I was thinking if you made a font that was only 5 pixels wide you could still have 80 columns without over-clocking... bonus! 83 columns. I assume a different font size would mess up the register settings you've discovered. Oh well... just tossing around ideas.
16
« on: February 28, 2013, 06:03 PM »
I didn't see this post before, but recently I tried and FAIL.
I tried with VICE 2.4 and VICE 2.3 and they both fail... in fact they screw up the serial bus and disk unit 8 is not accessible! (Disk unit 9 works).
I don't know about VICE 2.2, but VICE 2.1 kind of works... it doesn't mess up disk drive 8, and it produces an output when set to "file system" (I haven't tried real printer). The "file system" output is messed up when using CP/M (or I am doing something wrong)... I'm trying to print a simple text file in CP/M which uses plain 7-bit ASCII but the output file is "garbage". I think VICE is translating real ASCII (i.e., CP/M) as if it were PETSCII ("normal" aka BASIC, CBM text) into ASCII... of course this double-conversion is likely the problem... Unfortunately, VICE 2.1 does not offer "raw" output...
Well I imagine the CP/M issue is something unexpected by the VICE team, but the printer corrupting disk unit 8 in VICE 2.3 and 2.4 is truely a bug!
17
« on: February 28, 2013, 08:35 AM »
I was thinking of just one. 512k (largest available now) is just barely enough to compile CP/M, so something larger is really needed. The plan is to test the actual REU size and dynamically build a DPB, so it could also work with REU hacked for 1 or 2MB.
Of course there could be an advantage to having multiple RAM drives... 4x 4MB (M.N.O.P.) ? Hah, I guess there could be come some kind of partition utility written... Each extra drive takes up a few KB in bank 0, and there is about 8K free. But some of that should be left free for system extensions. Thinking about that, it probably would be best to limit it to just 2 RAM drives...
18
« on: February 26, 2013, 03:01 PM »
Well 1571 seemed to work for me in older versions, like v2.0, 2.1, 2.2... of course 1571 has always been strange... for example, good software will use track 1 then track 36, then track 2 and track 37, etc... this makes for the fastest seek time on real 1571 (because logical track 1 and track 36 are opposite sides of the disk = no head movement), but in VICE it will actually emulate delay from change between track 1 and track 36... a very long delay! Multiply that by multiple track pairs and VICE is insanely slow!! Although 1571 had "issues" like that in prior versions, at least it would work. Now it gives errors simply reading files or formatting disk... the format command seems fatal! After I tried format in VICE v2.4, it would refuse to mount the disk image in the future... as if VICE had corrupted its own file format!! Well anyway, as long as VICE team knows about the problem... I sent messages and if anybody here thinks 1571 is important, then please send them messages too... maybe it will be fixed in next release. * Anyway * (back to CP/M) I learned some new things about CP/M on the C128 due to extensive research since my last post... this seems not be undocumented or at least poorly documented. I think most of know that C128 implentation of CP/M can handle various physical sector sizes. Like standard 1571 uses 256-byte sectors, but "foreign" formats can be 128, 256, 512 or 1024-byte sectors. Of course 1581 uses 512-byte physical sectors. The interesting thing I noticed, which is was not obvious from existing documentation, is that BIOS treats all non-foreign (i.e., standard 1541/1571/1581) as having 1024-byte sectors! Pretty interesting since none of them use 1024-byte sectors! So BDOS sees all Commodore format disks as having 1024-byte sectors (not sure about foreign disk formats). Then BDOS requests a "physical sector" of 1024 bytes (the BDOS is "standard"), and the BIOS (customized by CBM) translates this into multiple sectors, as needed. I think the reason CBM did this is because CP/M shares disk buffers with all drives (except drive M, the REU). So 1024 is the smallest common factor among all the disk formats (including "foreign" formats). Anyway, it means CP/M is using double buffering! You (joe user) read a file from CP/M (e.g., HELP.HLP), then BDOS disects logical sector (better known as cluster) into "physical" sector and buffers the data... then BDOS makes request to BIOS of "physical" sectors. Then the CBM custom BIOS does more buffering for the really real physical sector size. (Of course the hardware takes care of the really really real physical sector size which includes sync marks, sector headers, CRC, blah blah blah). Okay, that is useless info #7 if wte is counting... I've lost track Another thing I noticed, in the "final" May 1987 release 768 unused bytes between $9700 and $9A00 in Bank 0. I could find no references to the area in the object code (ML) or the source code. As far as I can tell, CBM built CP/M Plus with a fixed address of $6000 for the start of disk buffers (grows upward in memory), while the required banked BDOS and BIOS grow downward in memory from $E000... in other words it is completely unused "middle" RAM. In previous posts I expressed concern about expanding size of allocation tables for larger disks like FD-4000 (3.xMB) or CMD-HD (up to 16MB)... but I did not know about this unused RAM. It remains to be seen what will happen with larger allocation table(s)... maybe they will fit in the unused area? Even if not, I think the total size would not grow very much considering this unused area exists. Also there seems to be small (about 128 bytes) unused area for printer#2 (aka, serial device #5) in the banked BIOS. Of course there are many ways to improve memory usage of BIOS... I don't want to do a total remake of the BIOS... just enough to get CMD drives to work... But I also noticed that REU is fixed to support only 128K or 512K... as long as I have to update BIOS, I think it would be good to add support for REU up to 16MB. What do you guys think ?
19
« on: February 26, 2013, 07:07 AM »
I've attached a simple program that lets you read/write sectors on fast-serial device. It works with 1571, 1581, uIEC... it seems to work with FD-2000, and FD-4000... at least in VICE. If you have some time and a real CMD FD or CMD HD, can you test and report how it works ... or doesn't work ? Thanks. * How to use it * Get the D64 image to a real Commodore. You can copy to real floppy or to a disk image with SD2IEC device (should also work with 1541 Ultimate). Once you have the disk loaded, RUN the first program (its BASIC). It will detect drive you loaded BASIC from, and then load a small ML program (it does fast-serial transfer). After, it will ask which unit is your CMD device. See first screen shot. Next it will send "Inquire Disk" command and display a menu. The menu is shown in second screen shot. At the top of the screen it will tell which unit is selected, the type of disk commands that will be used (logical or physical), and sector size (in hexadecimal). For logical format, the sector size is always 256 bytes ($0100). For physical format, it should be: - 256 bytes ($0100) for 1571
- 512 bytes ($0200) for 1581
- 1024 bytes ($0400) for FD-2000, and FD-4000. Also CMD-HD
 (Please report, thanks!)
The menu gives you 6 options (and Exit makes 7). These should be self-explanatory, but here is a brief summary. (1) Unit lets you choose a different disk unit, in case you entered the wrong value when the program started, or you have more drives you would like to try. (2) Sends "Inquire Disk" again. You should use this if you swap floppy disks... might also be needed after some read/write errors. (3) Toggle physical/logical command format. It defaults to physical because the 1571 does not support logical sectors like 1581 and CMD drives. See notes below. (4) Read sector. For logical format, you specify Track and Sector. For physical format, you must also specify a disk side (0 or 1). The data will be read into RAM starting at $C00 in bank 0. Again, see notes below. (5) Write sector. Almost the same as 4, but data is transfered from RAM to the disk and then written to the sector you specify. It also asks you to press RETURN to confirm. (6) View sector. This shows a hexadecimal dump of the data in RAM. It may display multiple pages, depending on 40/80 column display and the sector size. When it says "MORE" press almost any key to continue the listing or press ESC to return to the menu. * How it works * It sends BCIS commands to the disk drive. These are used in CP/M and some other software for fast read/write of sectors of data. This program only transfers 1 sector at time, but the commands allow multiple sectors to be transferred at once. Whenever it transmits a command that returns a BCIS status byte, or whenever it transmits/receives sector data, the ML program is called to do the transfer. While waiting for the fast-serial bus, the 40-column screen will flash colors. If for some reason the drive stops sending data, the computer would be stuck in an infinite loop (this is true of CP/M code and maybe KERNAL Phoenix)... however in ML program it tests for STOP key... so if the program stops responding for a long time, you can press STOP to regain control. If this happens, you should send a standard command like DIRECTORY to the drive to get its attention. * Notes about logical / physical command format * Now this could be confusing because Commodore changed the syntax of BCIS between 1571 and 1581. CMD drives use the 1581 flavor. So we'll ignore the 1571 here. With logical format, you do not specify a disk side, and sectors are always treated as 256 bytes. Also, the first sector on the disk is addressed as Track 1, Sector 0. For 1581, the sector number can be as large as 39 (i.e., 40 logical sectors/track). For CMD devices the sector number can be as large as 255 (i.e., 256 logical sectors/track). With physical format, you must also specify the disk side (disk head), and the sector size will depend on the device you use. The first sector on the disk is addressed as Side 0, Track 0, Sector 1. The maximum sector number should be: - 10 for 1581
- 10 for FD-2000 (assuming HD format)
- 20 for FD-4000 (assuming ED format)
- for CMD-HD (probably depends on particular hard drive)
There should be no harm if you specify a bad sector number. If it is bad, the drive just won't find it and report an error. BTW, if you are wondering why FD-2000 has same maximum sector as 1581, you should remember that FD-2000 physical format is 1024 bytes/sector, which is double the 1581 (and why FD-2000 can store about 1600KB compared to 800KB of 1581). The track number also varies. With logical format, the maximum track# is: - 80 for 1581
- 25 for FD-2000 (assuming HD format)
- 50 for FD-4000 (assuming ED format)
- Varies for CMD-HD.
As far as I can tell, all the drives will imediately report an error if you give a bad track# in logical format, so there is no danger. Be very careful with track# when using physical format commands! It seems the drive will try to seek to any track you specify, even an invalid track, which could ram the read/write head into the center spindle. With physical format, the maximum track# is: - 79 for 1581
- 80 for FD-2000 (assuming HD or ED format)
- 80 for FD-4000 (assuming HD or ED format)
- Varies for CMD-HD
Note the maximum track# is 1 less for 1581 because physical track# starts at zero (instead of one). This would also be true of FD drives, but they have an extra hidden track (would be track 81 in logical format, if it would allow you). This extra track is mostly empty, except for about 1K of data that defines the partition table. As far as I know, the physical format version of the BCIS "read sector" command is the only way to read this hidden information... i.e., using logical format BCIS commands or traditional U1 command will not work. Anyway, have fun reading sectors. * Background * This is a very simple test software. There are many ways it could be better. If you think it is lame, just know this is the "enhanced" version. The original was all ML without a nice BASIC front end. It was written (originaly) when I was writing fast-serial firmware for SD2IEC. Well I got "burst-load" to work with everything, and also "burst read/write" to work with D64 and D71 images. But it has recently been suggested to add support for D2M D4M DNP image in CP/M. I think that is a worthy goal, but it means "burst read/write" support must be expanded for SD2IEC, not to mention changes to CP/M itself (see this thread). I updated the software for additional testing before hacking CP/M. Well I did release a quick hack, but it only supports FD-2000, and only after you load it from a "normal" disk. In other words more testing is needed to make a real CP/M solution. Not only would it be nice for CP/M, but fast-serial support of CMD disk images would also be great in SD2IEC. The problem is I don't have real CMD hardware, just VICE. * Strange things with VICE * When I first tried this, I had terrible trouble with FD-4000. Later I got it working using FD-2000 and reported about it the CP/M thread... I thought everything was going well. But when I tried FD-4000 again, I was still getting bizarre behavior in VICE. One thing was I would constantly get "invalid block" errors, even when I specify valid (side)/track/sector. I found out one to get around the error: before issue BCIS "Inquire Disk", first issue BCIS "Set Status" with a value of zero. That is, $55 $30 $4C $00. This was not needed with 1581 or FD-2000. I never would have thought of it, except that I noticed that CP/M does this the first time it accesses a drive or after an error. Not sure why only FD-4000 needs it, but at least I got it working... Later I discovered that I could not access past logical track 25 on FD-4000, even though DIRECTORY reported 3MB size (i.e., 12736 Blocks Free). You should be able to access logical track up to 50!! Also it was not a problem with the BCIS commands. Using classic "U1" commands would not allow tracks greater than 25 either  However, using physical command format, I could access anything on the FD-4000. I looked at the hidden sectors on the reserved track, and the partition layout looked very similar to one of FD-2000. I think the FD-4000 image generated by VICE was corrupt. I did a "full format" of the same FD-4000 disk, and again it reported 12736 Blocks Free, but now access to logical track 50 is possible Either with BCIS or classic U1. So maybe there is a bug with "make disk image" in VICE ? Or I did something "wrong" ? Although the Directory and BAM used by CMD drives is well documented, I haven't found any good information on the CMD partition table in the hidden track. This lack of reliable information may be the root cause of the error... assuming the error isn't the user  EditFixed information about maximum physical track, added info about maximum sectors.
20
« on: February 26, 2013, 04:41 AM »
21
« on: February 26, 2013, 04:38 AM »
22
« on: February 11, 2013, 08:12 PM »
Now I'm triple posting, but this is a new issue... might need new thread, but anyway... any test code that you can share regarding the BCIS read sector problem?
I've attached test program I use... works with real 1571 and uIEC (with fast-serial upgrade). It should also work with 1581. Before I said that I got it to work in VICE with FD-2000/4000... well now I discovered a problem... It works fine for either logical or physical sector reading in VICE, but only with FD-2000!! I get error $a3 for both logical or physical reading of FD-4000... this error, which indicates Logical format (bit 7), sector size 512 bytes (bits 5,4), and invalid/missing block (low 4 bits) sounds like I am requesting bad track/sector, BUT the same error occurs with Inquire Disk (BCIS $04) which does not specify a track/sector (the drive should just test disk format). So there is a problem with FD-4000, either in reality or in VICE. Who knows about CMD-HD.... Also, there is SERIOUS problem with VICE in regards to 1571. I don't know if anyone noticed, but in VICEv2.4, a 1571 will sometimes (often for me) have read/write errors. I think they fû¢kéd up the emulator when they introduced FD-2000/4000. The sad thing is now they are working on SuperCPU emulation. (Just my opinion, but get existing stuff working before you try to add more $h!t) If you have problems with current VICE (v2.4) of simple 1571 commands (save, format, load) then you should email the VICE team and let them know (maybe it is just me?) Anyway, the attached disk image has a simple BASIC program that can be started with RUN"*"
if using unit 8... or just append ,U n where n is a different unit. The BASIC program will load an ML program if not already in memory and then give a menu... You can read/write/view any sector using either logical or physical addressing. Note only logical addressing is possible with 1571. Remember, physical addressing requires specification of disk side (head), and track/sector starts at 0/1. With logical addressing, track/sector starts at 1/0 (I really hope you understand the difference, but you can ask if not sure). When you view sector, it will pause after approximatley a full screen is displayed ($80 bytes in 40-column or $100 bytes in 80-column). When it says "PRESS A KEY" you can press ESC on real C128 (maps to F1 in WinVICE) to abort listing, any other key will continue. With logical format (256 byte sectors) there is only 1 page in 80-column or 2 pages in 40-column. It is really slow to view sectors in BASIC. If you are an experienced ML hacker, you can exit BASIC program and use MONITOR to view the current sector at $c00~xxxx (logical sector is $c00~$cff, 512 byte sector is $c00~dff, and 1024 byte sector is $c00~$fff). ... I used this software to create CP/M disk image of prior posts. In VICE it sometimes works with FD-2000, 1571, 1581 (buggy). It works for me using real 1571 and uIEC. If you have real FD-4000 or CMD-HD, I would be very interested to hear how it works (so I can get CP/M working with all CMD devices) EditFirst, the VICE email address mentioned above seems to be no longer valid... I checked on source forge and at least one other user has also reported problem with 1571... I tried to submit report but got an error... I also tried alternate link on source forge but also got an error... well I guess that means I need to create a source forge account? Yeah, right after I create a facebook account (=never). Well at least VICE team should know the problem exists, and I tried to tell them... if you have problems and know how to contact them, then please do. Second, the BCIS disk editor in this post will not work with 1541/2031/1551 or any other device that does not support fast-serial.
23
« on: February 11, 2013, 04:23 PM »
I think the 1986 version is the 2nd release. I believe only the 3rd / final release (May 1987) supports 1581. Anyone correct me if I'm wrong. I have a 1987 release on .d71 format, you can also find more common .d64 format elsewhere, such as here and here from zimmers. More trouble is getting the data to your C128. Easiest way, for me is to use memory card with SD2IEC device. Other people like to use XA1541 cable with software like StarCommander. If you don't have any of this hardware, it is recommended to spend the money, as it will save you lots of time and trouble in the long run. Another method (only recommended for hackers) is to type-in a program on your C128 that functions like Big Blue Reader (or Little Red Reader)... i.e., lets you read PC floppy disks. Even if you type-in correctly the 1571 has a lot of trouble reading disks from PC because most PCs have 80 tracks, and they write tracks which are much thinner than used by 1571 (makes them difficult to read with 1571)... I had to spend a lot of time writing on disk with PC and only after several tries could I get 1571 to read them... very frustrating! I can search for that software if you like... (a bit off topic, disks written in FAT format by 1571 are easy to read with PC, but that is moving data in the wrong direction) Regarding software for PC that can write in Commodore format: I haven't used it myself, but imagine it runs in DOS mode or Linux and works only with 3.5" disk... This might work for you, because you can start Win98 in DOS mode if you need. I don't know if this software works with 5.25" disk... well I know such software exists, but I'll shut up because I have no experience. If anyone knows of this kind of software, do tell! Anyway, you need to get at least FORMAT.COM, CPM+.SYS, and CCP.COM onto your C128 in CP/M format... then you can format a 3.5" disk and PIP any software you need.
24
« on: February 09, 2013, 06:23 PM »
CP/M can run on 1581, if the version on startup is May 1987. If it is, run FORMAT program in CP/M, then use PIP B:=A:CPM+.SYS and PIP B:=A:CCP.COM (assuming B: is your 1581, and A: has your system disk). These are the two files needed to boot CP/M, of course you would also want to copy some utilities as well... at least PIP and probably DIR, ERASE, FORMAT.
If you have an older version (for example August 1985), then you would need to download the newer version from the WWW and figure some way to transfer it to your C128. Easiest way, if you have PC with floppy, is to use tool that can write 1581 format... sorry I can't recommend one because I don't own 1581, so never did this myself.
(A long time ago I did write a program on C128 that would read PC 5.25 disk... Big Blue Reader is a program that does this too, but
you need Big Blue Reader before you can use Big Blue Reader! Also I doubt you have PC 5.25 disk)
A big problem with CP/M (in my opinion) is that it will only boot from drive 8. So if 1581 is not drive 8 (A: ), then you still have to boot with 1571... If you have some blank 5.25 disks, you can also try format and copy to them; they might (who knows?) work more reliable.
It sounds like your Blue Chip drive is more reliable. Is it like 1571? If so, I should keep a look-out for Blue Chip on eBay! I know both my 1571s have reliability issues because of their shoddy design.
25
« on: February 08, 2013, 08:57 PM »
Thanks! Not late in my opinion, as I have been waiting for the new issue in order to submit my 2 line entry for "lame game"
Pages: [1] 2 3 ... 49 Next
|
Show Posts
