0 Members and 1 Guest are viewing this topic.
WINSHELL = CMD
WINSHELL = COMMAND
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...
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)
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, 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!
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"...
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.
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.
It is impossible to brick the uIEC by loading new firmware via the SD card :-) Hack away!
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.
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.
If you replace the AtMega644 with the pin compatible Atmega1284 in the LarsP/MMC2IEC this not true anymore. It has 128kb flash memory, too.
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.
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 LOVE IT!!!! It's not perfect, but if you don't like it, byte me!
LFFFFFFFFFFFFFFFEA3f0000| 43 44 3a 43 50 4d 2e 46 41 53 54 2e 44 37 31 0d |CD:CPM.FAST.D71.|A28AefA3fA28Af0LEFA3f0000| 24 |$ |A48A60TVA5fA48A60T+A48A60TA5fA28Ae0A3fA28AffLEFA3f0000| 49 |I |A28AfdLEFA3f0000| 23 |# |A28A6fLFFFFFFFFFFFFEA3f0000| 55 31 3a 31 33 20 30 20 30 31 20 30 30 |U1:13 0 01 00 |A48A6dTVA5fA28AedA3fA28A6fLFEA3f0000| 55 49 |UI |A28AffLFFFFEA3f0000| 55 30 3e 56 31 |U0>V1 |A28AefA3fA28AffLFFFEA3f0000| 55 30 4c 00 |U0L. |A28A6fLFFFFFEA3f0000| 55 30 00 01 00 01 |U0.... |A28A6fLFFFFFEA3f0000| 55 30 00 01 00 01 |U0.... |A28A6fLFFFFFEA3f0000| 55 30 00 01 00 01 |U0.... |A28
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.
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.
OPEN 1,10,15: REM uIEC default unit 10PRINT#1,"CD:MYSOSSYS.D71": REM attach CP/M disk imagePRINT#1,"U0>"CHR$( 8 ): REM set uIEC to unit 8CLOSE 1BOOT
Wow, I am glad it works on PAL systems. Thanks for the report abraXxl. Quote from: abraXxlHydrophilic: 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...
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 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 10PRINT#1,"CD:MYSOSSYS.D71": REM attach CP/M disk imagePRINT#1,"U0>"CHR$( 8 ): REM set uIEC to unit 8CLOSE 1BOOT 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).
D 1400.01400 LDA #$00.01402 STA $FF00.01405 LDX #$08
bcis_status = (bcis_status & 0xf0) | 5; /* data checksum error */