SD2IEC (uIEC) update for Fast Serial

[Hydrophilic]

Having completed phase 3 of Media Player 128, the JiffyDOS "Proof of Concept" (or mis-concept, depending on your opinion of low video frame rates!), I now move onto phase 4, which is implementing fast-serial protocol in the SD2IEC firmware...

I only have a uIEC/SD to test this with, but as I understand the same firmware is used with MMC2IEC... also my main reason for this effort is for much improved Media Player performance, but it should benefit the C128 community in general... in particular CP/M should be possible at "fast" 1571/81 speeds instead of the pathetic 1541 speeds...

So I first went to the source and got SD2IEC firmware.  Next, for the Atmel compilation, I went to the vendor.  Unfortunately, the "C Tool Chain" (as they call it) only works on Win NT and not Win 9X....

Really bizarre if you ask me!  I see no reason why I can't compile source code with DOS (or CP/M if I wanted to do so)... well if the vendor sucks, go to the open-source community!  WinAVR was my next option and it runs fine on both Win 9X and Win NT.... (see notes below)

One important thing to note is that if you use Win 9X (95/98/ME) that you need to edit the Makefile around line 230 and change

WINSHELL = CMD

to

WINSHELL = COMMAND

Another important thing is that neither WinAVR nor the uIEC source code includes "CRCGEN-NEW" binary.  This is critical for updating the firmware of the uIEC (maybe MMC2IEC also).  It appends a CRC checksum to the binary so the firmware will accept and update the EEPROM.  I found a copy here, but haven't tested it yet.  (The last link seems to be the official SD2IEC "site")

Also strange about WinAVR is it seems to (re)install a complete POSIX-style build environment.  I have been using Cygwin and MySys for several years now to build Unix / Linux style binaries for Windows, so don't really see why I'd need to install another copy of cygwin.dll and all the other binaries... 

Anyway, an important thing to note about the WinAVR installer is that it semi-assumes your OS is installed on drive C.  If it is not installed on drive C, it will set AUTOEXEC.BAT on drive D (or other non-C drive) but Windows will only read AUTOEXEC.BAT from the boot drive (thus the drive D file is ignored).

I've come to expect this behavior with my hexadeci-boot system, but thought it would important to mention for others without the benefit of experience.

Anyway, I just thought toss out my experiences thus far and ask for any/all opinions regarding firmware builds for uIEC / MMC before I brick my own hardware... thanks!

About the code... if the above isn't clear, let me state it plainly... I'm working on the code but haven't tested it yet.  Right now I have uIEC to output fast-serial using a "rigid" software loop like used with JiffyDOS / Final Cartridge 3.  This isn't the optimal way and does not support fast-serial input yet... that would require re-configuring the hardware... not something I'm up to yet...

The #1 priority is to implement Burst-Load (for MP 128) but would also like to implement Inquire Disk, Log Disk, Sector Read, and Sector Write (for CP/M etc.).  So like I said, the code is coming along, but would like some feedback before trying to burn my device...

[abraXxl]

Hey!

Nice to see some work for the fast serial protocol.
Have you contacted with Unseen@Forum64 one of the devs behind the sd2iec firmware? Perhaps he can give you some advice.

I have contributed the Nippon fastloader subroutines with an also simple loop. For the burst protocol I guess a better integration into the sd2iec architecture is needed and far above my knowlegde about the sd2iec sources.

It is often handy to have an serial console cables (USB-RS323) ready for debugging.
What strange effects can happen in WinDos specific build environments I can't tell, my build environment is Ubuntu Lucid, where
"apt-get install avr-gcc avrdude make gawk vim" installed all neccesary for me.

[Hydrophilic]

No, but thanks for the link!  I just downloaded the latest SD2IEC source, as the one I had been working with is a few years old.  Older is usually simpler.  KISS.

Anyway, many new docs by Ingo Korb.  Really good read if your into disk drive codes.  Interesting to see other peoples take on stuff like Epyx and GEOS fastloader and copy protection.  I believe he received the bounty for the GEOS implementation.

I don't think I would have got very heavy into ML programming or into controller programming at all, if it were not for those pesky copy protection schemes that always begged me to break them.  See there is some good in copy protection

[Hydrophilic]

I wanted to report my progress with the SD2IEC firmware for fast-serial support.  The good news is that I only half-bricked my uIEC     Read below for details or try another thread if you're in a hurry (long post).

I got fast-serial output working with only a minimal amount of debugging.  Then I wanted to go to the next level and start implementing the Burst Command Instruction Set (BCIS).  These are the "U0" commands without friendly character interface.

Well the most popular command of the BCIS seems to be the "change utility", command $1e, which (because flags are ignored for this instruction) can be entered as $3e ... which leads to yea old favorite "U0>??" commands.

Even devices that do not support fast-serial or BCIS often support sub-commands of this function.  Such as...

   
• U0>(device#)
• U0>S(sector inteleave)
• U0>R(error retries)
• U0>Vn (verify off or on)
• U0>Mn (switch 1541/71 emulation)

But the $1e command is only one of several BCIS instructions.  Because my primary motivation is fast-serial loading for Media Player 128, I was really interested in the $1f command -- a.k.a. "burst load"

But the $1f command is one of the more complex instructions.  The only one more difficult would be "format disk" which takes many, many, parameters due to the MFM (a.k.a. "foreign CP/M") disk capabilities of the 1571 and 1581.

So the simplest BCIS command, which actually returns information (unlike U0>Rx for example, which only accepts data), would be $04, "Inquire Disk".  This command returns a single status byte using fast-serial protocol.

And yet this simplest of commands is something that Commodore managed to screw up.  On the 1571, this command will return $01 for "ok - GCR format" but it has a wrong sector size (bits 4,5)... if you were to interpret the value per these bits, you would think a standard 1541/1571 disk had 128 byte sectors... well I'm sure anyone who has read this far knows these 5.25 floppies have 256 byte sectors...

However, Commodore says the sector size (and other disk info) is invalid if bit 7 is clear ... meaning GCR / CBM format... Bit 7 is clear in the value $01 but...

If you execute "inquire disk" (command $04 remember) on a standard 1581 disk you get a value of $20, meaning "GCR / CBM format" with 512-byte sectors.  Well first, if it is GCR/CBM, then I don't see how it could be 512-byte sector... and second, considering 1581 really does use 512-byte sectors, it should also report MFM format (since that is reality)... that is, it should be honest and say $A0 (MFM 512) or lie and say $01 (GCR sector size implied) or maybe $10 (GCR 256 -- logical format).  We've all read the 1581 manual and know the difference between logical and physical formats right?  Thought so.

So anyway, the 1581 can't tell the truth and it can't tell a good lie either!  Well, there you have one way to distinguish a 1581 from other devices...

Faced with this conundrum, I just programmed the SD2IEC to report $01 like the 1571 since most software seems to come on 1571-compatible .D64 disk images.

Moving along, the next more complicated command (and very useful by the way), is command $00 or "Read Sectors".  This is the fast-serial equivalant of yea old favorite "U1" or yea old hated "B-R" commands.

This works well enough with a 1571.  But when you try it on a 1581... incompatibilities again... thanks Commodore!  That was sarcasm.

On a 1581, the same instruction seems to do "physical-to-logical" or maybe "logical-to-physical" conversion.  I'm not sure which... here is what I know...

On a 1571, if you tell it to read track 1, sector 0 (every C128 fan's favorite boot sector), then you really get the boot sector.  Nice.

On a 1581, if you issue the same command, you get an error because the 1581 doesn't like sectors numbered 0.  So if you change the command to read track 1, sector 1, then you get... track 2 sector 0!!!  This is because the 1581, being MFM based, starts numbering tracks at 0 instead of 1... and numbering sectors at 1 instead of 0 (but remember it does NOT report MFM when you "Inquire Disk").

So now the 1581 is pissing me off.  Anyway, I programmed the SD2IEC firmware to act like a 1571 and give you the boot sector when you ask for track 1 sector 0.  How hard was that?  Not hard for me... too difficult a concept for CBM appearantly...

[Disclaimer]
I have 2 1571s in addition to my uIEC.  One 1571 has original CBM ROM and the other has JiffyDOS.  I do not have a 1581.  The 1581 testing was done using VICE.  So it is possible the problem is with VICE or is completely my fault.
[/Disclaimer]

Moving along... so we got single byte fast-serial working (Inquire Disk) and we got entire sector (256 byte/command) or even multiple sectors (but only on the same track).  Next we have command $1f, "Burst Load".  This takes an actual file name (which thankfully the 1581 doesn't screw up) and loads multiple sectors anywhere on the disk... sweet!

Now there are several devices that use the SD2IEC firmware, but I only have a uIEC to test with.  (I recommend it by the way.)  When you issue a Directory command, the funny thing about the device is that it lists the file size in terms of FAT clusters... definately not the same (often MUCH larger) than a standard CBM "block"...

Anyway, the first file I decided to "burst load" was one that appeared in the directory as 240 blocks or so (don't know the exact value).  Now if these were normal GCR / 256-byte blocks, it would all load in Bank 1 (where I load stuff for testing).

So I burst-load "COMMAND.COM" in my first test (the DOS 6.22 version, because I'm a dork) and am initially pleased to see that it starts loading without error, but then am I bit suprised and disappointed when my computer crashes...

Because the file size was in clusters (I'm guessing about 2048 bytes) instead of normal 256-blocks, the file was WAY WAY too large to fit in Bank 1, and thus (due to my hasty programming), trashed the MMU and/or CPU vectors in the $FF00 region of memory...

So after a 0.5 second reboot (beat that Micosoft!), I was quite pleased to find that COMMAND.COM loaded successfully into RAM Bank 1 (well, up until $FF00).

Having said all that, let me back up a bit and say that everything had been working fine.  In particular: LOAD, SAVE, VERIFY, and SCRATCH.  I saved my slightly modded C128 code from the ML Monitor (the code I was using to test the BCIS / fast-serial) without trouble.  But when I tried to VERIFY, I got an error...

Naturally this was quite disturbing... I was able to list directories, save, and scratch files... but would get I/O ERROR #5 (device not present) whenever I tried to load or verify a file...

To save you more boring details, let's just say I discovered load/verify does work correctly... in C64 mode...

So it seems the C128 is trying to issue "burst-load" (or verify) to my uIEC, even though I have not yet programmed it respond with "fast-serial support"... that is one of those JiffyDOS-like protocol changes that occurs inbetween serial commands (in this case, when the KERNAL pull ATN low, but before it sends the device address in a TALK/LISTEN command).

To summarize, 3 new BCIS commands are working using fast-serial protocol (in addition to the previous commands that did not require fast-serial).  But the "burst-load" only works when issued from my debug software and causes "device not present" error when standard BASIC / KERNAL commands are used.

So I just need to add the proper "fast serial acknowledge" to the firmware, and it should work fine with KERNAL / BASIC.  I would also like to get a few more BCIS instructions working so I can test it with CP/M.  CP/M is the most disk-intensive software I can think of, except for GEOS.  But it doesn't count because it uses custom software drivers.

Oh yeah, I wanted to report about the speed.  Sorry I don't have any exact numbers for you yet, but it is fast... REALLY FAST.  Okay, it is not REU fast or anything, but it is faster than 1581 JiffyDOS... if that means anything to you!

[abraXxl]

Well, nice to see some progress here

Are the patches avaiable for public testing and does Unseen Pull them into his git-Repository? Are in contact with him, so that patches don't get lost.

What is the AVR pin you used for SRQ.
I have 3 of these PCBs - called LarsP layout with Atmega 644/1284 running SD2IEC Firmware. I would happily test and adopt this to LarsP layout.

[Hydrophilic]

I haven't posted any code yet.  Will do once I get the "fast serial acknowledge" fixed... until then, C128 users would have to GO64 in order to LOAD anything... or use my custom debug software which ignores this detail... either of which is NOT user friendly... more like user angry 

The SD2IEC sources already have SRQ defined.  There is IEC_OBIT_SRQ, which an actual bitmask for the IEC output port, and there is IEC_OPIN_SRQ which is the actual bit-number.  I checked the assembly listing after build, and noticed this comes out to $80 (bitmask) or 7 (bit-number) for I/O port 0x03 (input) or port 0x0b (output)... if memory serves correctly (the build was done on a different PC).  More importantly, this was built using the uIEC / Atmega1281 configuration, could easily be different for other devices. 

[abraXxl]

I understand your concerns. What is the problem with the fast serial handshake? My understandig, I got from here and here, both communiation partners try to transfer a byte via SRQ/ATN. If the transfer was successful, a flag is set, that indicates that both are capable for fast transfer mode. You also want to have a look in the source for the XS1541, a XU/XUM1541-like device that runs on the LarsP-Layout, too. It can do fast serial transfer with 1571/81 drives. Perhaps it helps.

[Diddl]

You can take the sources to my XS-1541 where code for fast serial (burst mode) is included. It is code for the same controller as SD2IEC (MMC2IEC) and not far away from the controller in the µIEC. So it should be very easy to add burstmode into SD2IEC.

The problem is, most of the SD2IEC devices doesn't support SRQ line in hardware. Has this µIEC hardware support for SRQ?

[Hydrophilic]

Yes, Diddl, uIEC has support for SRQ.

Thanks for the links, abraXxl,  I am muddling my way through fast-serial alone for the moment (experience is the best teacher).  I'll be sure to check them out if I get stuck.

The problem (as previously reported), was I had not programmed the SD2IEC to send a proper "fast-serial acknowledge" because, then, the C128 would want to transmit fast-serial and I had not got far enough on the SD2IEC to accept fast-serial.  I hope that makes sense!

In other words, the first run was just SD2IEC transmitting and C128 receiving, and not the other way around... but the C128 KERNAL doesn't like a half-way job...

Anyway, I wanted to report that I implemented the "fast-serial acknowledge" and at first had trouble...

Everything worked fine in C64 mode (at least I didn't break slow serial), but in C128 mode, I could only read the error channel... could not send any commands or load any files... So that was one step back...

Some investigation revealed the C128 was indeed receiving "fast-serial acknowledge" but there was an error sending data from C128 to SD2IEC...

It turns out the standard Listen routines, even though re-coded to accept fast-serial, were still too slow.  So I went hard-core on the firmware (yea for bit-banging) and now the code is sending and receiving fast-serial.

So now all the standard commands are working again in C128 mode, but there is still a problem with the ever-important "burst load".  Remember I said COMMAND.COM was too big to fit in Bank 1?  Well I was wrong... it is only 54 kiByte.  There is a problem with the fast-load detecting end-of-file!

Almost there... should just be a minor detail to fix... then I can report some actual speeds and get back to Media Player 128.

P.S. I checked the assembly listing, and SRQ is definately input on bit 7 of port 0x3 and output on bit 7 of port 0xb... again this is for Atmega1281 / uIEC configuration; can't say about anything else...

[brain]

I only have a uIEC/SD to test this with, but as I understand the same firmware is used with MMC2IEC... also my main reason for this effort is for much improved Media Player performance, but it should benefit the C128 community in general... in particular CP/M should be possible at "fast" 1571/81 speeds instead of the pathetic 1541 speeds...

The firmware, at one point a year or so back, would still fit in the MMC2IEC hardware, but no longer.

Really bizarre if you ask me!  I see no reason why I can't compile source code with DOS (or CP/M if I wanted to do so)... well if the vendor sucks, go to the open-source community!  WinAVR was my next option and it runs fine on both Win 9X and Win NT.... (see notes below)

Well, I wouldn't call that bizarre.  Win98 hasn't been supported by mainline toolchains for some time.  I am surprised WinAVR supports it still.

Another important thing is that neither WinAVR nor the uIEC source code includes "CRCGEN-NEW" binary.  This is critical for updating the firmware of the uIEC (maybe MMC2IEC also).  It appends a CRC checksum to the binary so the firmware will accept and update the EEPROM.  I found a copy here, but haven't tested it yet.  (The last link seems to be the official SD2IEC "site")

Hmm, I'll consider adding it to the files...

Also strange about WinAVR is it seems to (re)install a complete POSIX-style build environment.  I have been using Cygwin and MySys for several years now to build Unix / Linux style binaries for Windows, so don't really see why I'd need to install another copy of cygwin.dll and all the other binaries... 

It does that because, it can't depend on your copy being new enough, and it can't depend on it already being installed.

Anyway, I just thought toss out my experiences thus far and ask for any/all opinions regarding firmware builds for uIEC / MMC before I brick my own hardware... thanks!

It is impossible to brick the uIEC by loading new firmware via the SD card :-)  Hack away!

[brain]

Now there are several devices that use the SD2IEC firmware, but I only have a uIEC to test with.  (I recommend it by the way.)  When you issue a Directory command, the funny thing about the device is that it lists the file size in terms of FAT clusters... definately not the same (often MUCH larger) than a standard CBM "block"...

Correct, though if you want to have it report BLOCKs, you can modify the code in fatops.c:fat_freeblocks().  return clusters should be switched to return freeblocks * 512/ 254 to be perfect, or freeblocks * 2 to be close enough.  if you do change it, ensure you change the if statement so the maximum value returned is 65535.

If you're planning to implement the boot sector in sd2iec, please let me know.  It would be best to implement it two different ways.  When not in an image, it should load a boot.img file in the root directory, or something like that.

Jim

[brain]

Well, nice to see some progress here

Are the patches avaiable for public testing and does Unseen Pull them into his git-Repository? Are in contact with him, so that patches don't get lost.

What is the AVR pin you used for SRQ.
I have 3 of these PCBs - called LarsP layout with Atmega 644/1284 running SD2IEC Firmware. I would happily test and adopt this to LarsP layout.

Sadly, LarsP does not support the SRQ line, but maybe you can solder a wire to the correct pin and update the firmware defines to add support for the pin.

[brain]

uIEC supports SRQ line.  It was designed into the project in anticipation of eventual fast serial support.

The larger issue with this added firmware support if the firmware image size.  Currently, the sd2iec firmware is approaching 60K, and only uIEC (with 124K of firmware space) can hold larger firmware images.

Jim

[abraXxl]

The firmware, at one point a year or so back, would still fit in the MMC2IEC hardware, but no longer.

The larger issue with this added firmware support if the firmware image size.  Currently, the sd2iec firmware is approaching 60K, and only uIEC (with 124K of firmware space) can hold larger firmware images.

If you replace the AtMega644 with the pin compatible Atmega1284 in the LarsP/MMC2IEC this not true anymore. It has 128kb flash memory, too.

It is impossible to brick the uIEC by loading new firmware via the SD card :-)  Hack away!

The bootloader scans for files in rootfs with a specific size. For LarsP/MMC2IEC/Atmega644 the size is 61440 bytes and for uIEC/1281 and Larsp/1284 it is 126976 bytes. To ensure that the devices stays functional a specific hardware id is also encoded in the flash file, the version is also compared. The new to be flashed firmware version must be newer than the old.

Sadly, LarsP does not support the SRQ line, but maybe you can solder a wire to the correct pin and update the firmware defines to add support for the pin.

As far figured out by today, some people like PeterSieg/Diddl use pin PC3 for SRQ on the 328/644/1284 with LarsP layout.

If you're planning to implement the boot sector in sd2iec, please let me know.  It would be best to implement it two different ways.  When not in an image, it should load a boot.img file in the root directory, or something like that.

I like the way the XR: command works for rom images. So here my idea. The command XC: is free (e_X_tended commands _C_128 bootsector). XC:filename. If sd2iec firmware is in native filesystem mode and track,sector 1,0 is requested the first 256 byte block of the file is sent. The file is firstly searched in current directory and then in the root filesystem. This way you could also implement longer sector chains to be read as bootsector. Just send the following 256 byte block of the file are send.

:wq

[Hydrophilic]

I LOVE IT!!!!          It's not perfect, but if you don't like it, byte me!

Before I forget, thanks a lot for your posts Jim, very informative.

So some quick stats before I get to the boring details

Test	Format	Load--	Save
Standard (slow)	FAT	66.9s	51.7s
CP/M (slow)	D71	87.1s	...
CP/M (fast)	D71	11.9s	...
JiffyDOS	D81	6.03s	42.9s
JiffyDOS	FAT	6.00s	21.6s
Fast-serial	D81	5.12s	48.9s
Fast-serial	FAT	4.98s	27.5s

All the load / save times are from 142 block file on a uIEC connected to NTSC C128... the exeption is CP/M where I just timed the boot process (from BOOTING message until A> prompt).  I forgot to test the load/save on a D64/71/81 using slow serial... so sue me.

As you can see, the load times are about 20% faster when using fast-serial compared to JiffyDOS, and about 1240% faster (!) when compared to standard (slow) serial.  Also you may notice some weird things in the table... like standard serial will Save faster than Load!!  Also JiffyDOS will save about 28% faster than fast-serial (but it's the loading that counts, right?)  You can also see that load times are a tiny bit faster using the native (FAT) file system as opposed to a disk image (D64/D71/81), but the save times are about 2x faster on the native file system... hmmm...

If you're wondering why most of disk images are D81 except for the CP/M test, it is because there are two types of fast-serial... there is the normal fast-serial used by the KERNAL for LOAD/SAVE/VERIFY and then there are special "Burst Command Instruction Set" commands (BCIS) that are used by CP/M when it detects a capable device (1571, 1581, or likely CMD-HD).  The 1571 will use "native" sector sizes (256 bytes) and "native" block specifiers (start at Track 1, Sector 0).  But the 1581 (maybe CMD-HD) uses 512 byte sectors and "CHS" block specifiers (start Track 0, Sector 1).

Long story short, I don't have the time or motivation to implement the CHS system, so the BCIS commands that use cylinder/head/sector specifiers will fail, like on D81... also on DNP, but that is mainly because I don't have any DNP images for testing.

In other words, I took the extra time to make sure that CP/M would at least work with "standard" block specifiers, like on D64 and D71 disks.  Actually, I don't know why!  I'm not a big CP/M fan... it is more of a curiousity to me... like DOS or Win3.11...

The important thing, for most software in general and Media Player 128 in particular, is that burst-load works... it works fast... and it works with any type of disk image or the native file system. 

I've attached a binary that you can use to flash a uIEC.  It is a "prerelease" version which means you can replace it with any other version if you don't like it.  More importantly, it is based on older code (0.8.2) that does not have GEOS support and may not have support for DNP images ... if somebody has a DNP image to contribute, that would be nice!

Also attached are the source files so other people can fix everything I messed up!  This is my first experience with the AVR, so have a good laugh at my code.    If any of you are decent C and assembly programers, I recommend playing with it.  I learned a lot... mainly how much I still need to learn! 

This is one of those things somebody could spend months working on, but I gotta get back to Media Player 128... I just can't wait to see what happens!!!  I mean 20% improvement might not sound like much, but the raw transfer speed is not as important as the fact that (once data is known available), it can be "aquired" with 1 instruction (LDA $DC0C), as opposed to 16+ intructions required for JiffyDOS... AND there is no need to wait to avoid VIC bad lines... AND there is no need to use 1MHz... I'm pretty psyched, can you tell?

P.S.
My amount of testing has been fairly minimal.  Burst-load seems reliable after mutltiple tests, and that is the main reason (for MP128) for this side-quest.  In particular, I recommend you not use it for saving important data... at least not until you've had a chance to test it for yourself... I only had trouble with BCIS (CP/M type) saving, and it was quickly fixed... however the testing was very minor because, again, burst-load was most important to me.

I took the extra time to implement most of the BCIS instructions.  The only instruction not implemented is "burst format".  I had planned to simply change the command string into a normal "NEW/HEADER" command and pass it to the existing code, but there is no existing format code (at least not in this old version)...

I could go on and on, but will shut up for now and post a more complete write-up on my website... when I find the time from working on MP128 of course...

[brain]

If you replace the AtMega644 with the pin compatible Atmega1284 in the LarsP/MMC2IEC this not true anymore. It has 128kb flash memory, too.

I limited my comments to something almost everyone can do.  Yes, if you replace the uC, all things are possible, but doing so implies the user has a programmer and potentially can solder (some of the MMC2IEC variants are surface mount.

The bootloader scans for files in rootfs with a specific size. For LarsP/MMC2IEC/Atmega644 the size is 61440 bytes and for uIEC/1281 and Larsp/1284 it is 126976 bytes. To ensure that the devices stays functional a specific hardware id is also encoded in the flash file, the version is also compared. The new to be flashed firmware version must be newer than the old.

Since we're clarifying, it is not completely true the version must be newer.  Versions of 0.0.0.0 will overwrite anything in the flash, assuming the CRC is different than the image already on FLASH.  This is how we create development images.  The Makefile will take care of this for you if you simply uncomment the line adding "PRE" to the version string.

I like the way the XR: command works for rom images. So here my idea. The command XC: is free (e_X_tended commands _C_128 bootsector). XC:filename. If sd2iec firmware is in native filesystem mode and track,sector 1,0 is requested the first 256 byte block of the file is sent. The file is firstly searched in current directory and then in the root filesystem. This way you could also implement longer sector chains to be read as bootsector. Just send the following 256 byte block of the file are send.

:wq

I'm leery of providing that much flexibility.  I'd rather use the "boot.img" naming in the code, looking for it in the dirs as you indicate, and then see who finds that approach too inflexible.

Why?

XR was added because a user, rightly so, might need to run multiple ROMs during the course of a session.  -XR was an easy way to add that to some code, so folks could do:

1 open15,10,15,"XR:...."
...

and ensure their application worked.  I'm not convinced folks need that level of flexibility in a boot record.  It's typically used once per computing session.

I'm happy to be wrong, but I think it is more prudent, given the scarcity of EEPROM locations, to start with my approach. If there are feature requests to apply more flexibility, at least we know there is a large enough user base to allow the additional feature.

Jim

[brain]

I LOVE IT!!!!          It's not perfect, but if you don't like it, byte me!

Did you make your changes against the newest source in Ingo's GIT repo?

Jim

BTW, note that the uIEC has a Google Group Mailing List:  'uIEC-users'  You might want to join if not already on.

Jim

[abraXxl]

I adopted the your fast serial patch to current HEAD in Unseen's git repository.
Patch attached.
It still fits in Atmega 644  But I tested on Atmega 1284

The fast load in C128 mode works here C128/PAL. I tested with Risen from the Oblivion VDC v2 (227 blocks). It loads in ca 7.9 seconds wow.
But CP/M doesn't work. CP/M is stuck in boot screen "booting cp/m plus" - "read error - hit return to retry" "del to enter c128 mode"

For recving a byte via fast IEC i added a debug statement uart_putc('F'); to know if bytes are really transfered via your routine. It works.

Here the serial debug for booting cpm.d71

Code Select Expand


LFFFFFFFFFFFFFFFEA3f
0000| 43 44 3a 43 50 4d 2e 46 41 53 54 2e 44 37 31 0d |CD:CPM.FAST.D71.|
A28
Aef
A3f
A28
Af0
LEFA3f
0000| 24                                              |$               |
A48
A60
TVA5f
A48
A60
T+A48
A60
TA5f
A28
Ae0
A3f
A28
Aff
LEFA3f
0000| 49                                              |I               |
A28
Afd
LEFA3f
0000| 23                                              |#               |
A28
A6f
LFFFFFFFFFFFFEA3f
0000| 55 31 3a 31 33 20 30 20 30 31 20 30 30          |U1:13 0 01 00   |
A48
A6d
TVA5f
A28
Aed
A3f
A28
A6f
LFEA3f
0000| 55 49                                           |UI              |
A28
Aff
LFFFFEA3f
0000| 55 30 3e 56 31                                  |U0>V1           |
A28
Aef
A3f
A28
Aff
LFFFEA3f
0000| 55 30 4c 00                                     |U0L.            |
A28
A6f
LFFFFFEA3f
0000| 55 30 00 01 00 01                               |U0....          |
A28
A6f
LFFFFFEA3f
0000| 55 30 00 01 00 01                               |U0....          |
A28
A6f
LFFFFFEA3f
0000| 55 30 00 01 00 01                               |U0....          |
A28

This implies to me that something goes wrong in "U0"+chr$(00) command: burst read.
@hydropholic:
If you have time, please check out current git and test my patch, perhaps you see what I have missed.

Thank you for your work.  I love it, too.

@brain: Concerning the Bootrom code.

and ensure their application worked.  I'm not convinced folks need that level of flexibility in a boot record.  It's typically used once per computing session.

You're right. Yes, a hard coded BOOT.BIN would be sufficent for most users.
I do same for the ROM images with XR:FLOPPY.ROM written in my MMC2IEC devices. This file searched firstly in current directory by the firmware and then in root directory. In my Geos work directories is placed a FAKEHD.ROM, to mimic a CMD-HD drive. So I am not using this flexibility of the XR-Command.

[brain]

abraXxl, thanks for the patch against HEAD.  I was planning to try to merge the changes into HEAD this weekend, but you beat me to it.Jim

[abraXxl]

short bug report:
Hydrophilic: your implementation and my port has a problem if a datasette is connected to C64/C128@C64 mode. It simply hangs like the 1581 in the same scenario.

[brain]

As well, I tried to submit the patch for inclusion, but Ingo would like an email from Hydophilic for legal reasons.

Jim

[Hydrophilic]

Wow, I am glad it works on PAL systems.  Thanks for the report abraXxl.

Hydrophilic: your implementation and my port has a problem if a datasette is connected to C64/C128@C64 mode. It simply hangs like the 1581 in the same scenario.

First time I've heard of anything like that.  I never owned a 1581, and haven't seen a datasette in years (me and my friends are still wondering what happened to the one we had years ago...).  I was only able to test that it works with 1571(s) attached (in 1571 and/or 1541 mode).

I never even thought to try C64 mode... well, actually I had to use C64 mode for loading with a defective fast serial version... but once I got fast serial working, I totally forgot to try C64 mode again.  Anyway, it would not matter because I don't have a datasette to test with.

If anybody knows more about the C64 / 1581 bug, then it might be possible (from that info) to fix the firmware...

I don't understand the UART dump... but I do know I had problems like you described at one point, and it was a similar problem.  Whenever there is a "disk change", either by insert new memory card, or "disk swap" button, or "CD" into disk image, then the firmware is coded to act like a 1571 and set "disk ID mismatch" until a BCIS "log in" occurs.

The "log in" can be with BCIS command "Inquire Disk" or "Query Status" as I recall... I don't have the code in front of me to tell you which U0 commands these are (I'm thinking code $0c is one).

Anyway, I had the problem described, where you get "booting cp/m plus" - "read error - hit return to retry".  This was fixed (for me) by changing firmware to clear the "disk change" when either BCIS command described above was sent.  So I could do this...

OPEN 1,10,15: REM uIEC default unit 10
PRINT#1,"CD:MYSOSSYS.D71": REM attach CP/M disk image
PRINT#1,"U0>"CHR$( 8 ): REM set uIEC to unit 8
CLOSE 1
BOOT

Umm... maybe I attached the disk image after changing the device number, but I don't think it would matter.  Anyway, CP/M worked for me, so I don't know the problem.... as I recall, the CP/M boot process will send the BCIS $0c command before any read sector commands, and it will also send it again after CP/M system is loaded but just before the A> prompt appears (I'm guessing this is just before CCP.COM is loaded).  Also the BCIS $0c command has high bit flags, and as I recall the actuall code sent is $4c (i.e., $55 $30 $4C $00).

I guess I can take a look and see if there is some obvious problem... BTW, I have no idea what HEAD is... can somebody explain?

I sent Ingo an email, so maybe fast serial will get integrated into the main line firmware...

[abraXxl]

Wow, I am glad it works on PAL systems.  Thanks for the report abraXxl.

Hydrophilic: your implementation and my port has a problem if a datasette is connected to C64/C128@C64 mode. It simply hangs like the 1581 in the same scenario.

First time I've heard of anything like that.  I never owned a 1581, and haven't seen a datasette in years (me and my friends are still wondering what happened to the one we had years ago...).  I was only able to test that it works with 1571(s) attached (in 1571 and/or 1541 mode).

If anybody knows more about the C64 / 1581 bug, then it might be possible (from that info) to fix the firmware...

You assume while procession ATN and after you have sent the fast serial impulse, that if SRQ is low, the master C128 is able to do the fast serial protocol.
In C64 mode or on a real C64 SRQ is connected with the FLAG line on the datasette port. There some datasette models out there that pull FLAG down and so SRQ if the cassete motor is off.
There are also many hardware implementations out there that have SRQ not connected, so the SRQ pin is floating with no well defined input.

AFAIK The correct way is to wait for eight SRQ pulses. If you have received this indicator for the fast serial protocol from master, then and only then the sd2iec should send the eight SRQ pulses and only then wait for SRQ low.

I guess I can take a look and see if there is some obvious problem... BTW, I have no idea what HEAD is... can somebody explain?

HEAD is the last checked in revision of code from a git repository. eg. if you simple type git clone http://www.sd2iec.de/sd2iec.git you get HEAD.
git pull and git diff are also handy

I don't understand the UART dump... but I do know I had problems like you described at one point, and it was a similar problem.  Whenever there is a "disk change", either by insert new memory card, or "disk swap" button, or "CD" into disk image, then the firmware is coded to act like a 1571 and set "disk ID mismatch" until a BCIS "log in" occurs.

The "log in" can be with BCIS command "Inquire Disk" or "Query Status" as I recall... I don't have the code in front of me to tell you which U0 commands these are (I'm thinking code $0c is one).

Anyway, I had the problem described, where you get "booting cp/m plus" - "read error - hit return to retry".  This was fixed (for me) by changing firmware to clear the "disk change" when either BCIS command described above was sent.  So I could do this...

OPEN 1,10,15: REM uIEC default unit 10
PRINT#1,"CD:MYSOSSYS.D71": REM attach CP/M disk image
PRINT#1,"U0>"CHR$( 8 ): REM set uIEC to unit 8
CLOSE 1
BOOT

Umm... maybe I attached the disk image after changing the device number, but I don't think it would matter.  Anyway, CP/M worked for me, so I don't know the problem.... as I recall, the CP/M boot process will send the BCIS $0c command before any read sector commands, and it will also send it again after CP/M system is loaded but just before the A> prompt appears (I'm guessing this is just before CCP.COM is loaded).  Also the BCIS $0c command has high bit flags, and as I recall the actuall code sent is $4c (i.e., $55 $30 $4C $00).

You're right $55,$30,$4c,$00 (INQUIRE STAUTS) is sent and the following reads ($55 $30 $00 $01 $00 $01) seem to fail .
I have no idea why.