|
|
Post by hydrophilic on Nov 14, 2014 6:31:12 GMT
Below is the D71 file I use for CP/M (on the rare occasions that I actually use CP/M  ). It is the last official release by Commodore, but it has Y2K patches. It does not include any new features (like Jugler or ZPM).
CPMY2K.D71 (341.5 KB)
Warning: CP/M runs terribly slow with: - a 1541 (unless you have JiffyDOS in *both* your C128 and your 1541)
- SD/MMC (like uIEC) that does NOT support fast-serial (moderately fast if your C128 has JiffyDOS)
I don't have JiffyDOS in my C128, but it runs quite fast because my uIEC has fast-serial (faster than 1571 or 1581). In other words, you need a fast-serial 'disk' device, or BOTH your device and your C128 must support JiffyDOS (the C128 and 1571 naturally supports fast-serial).
Lots of C128-Specific documentation of CP/M is available here.
Edit On a more positive view, here are my recommendations (in order of speed): - C128 + uIEC with Fast-Serial [fastest]
- C128 + CMD FD/HD Drive (native Fast-Serial)
- C128 + C1581 (native Fast-Serial)
- C128 + C1571 (native Fast-Serial)
- C128 with JiffyDOS + sd2iec (uIEC / MMC)
- C128 with JiffyDOS + C1541 with JiffyDOS
- C128 + C1541 [slowest]
In regards to SD2IEC, only uIEC is known to support Fast-Serial (no known version for MMC). Jim Brain specifically designed the uIEC to support fast-serial, which is what I added to the firmware. I am not sure if MMC can support fast-serial by any method! /Edit
|
|
|
|
Post by donno128 on Nov 23, 2014 4:57:03 GMT
Your uIEC has fast serial? I didn't know there was fast serial for uIEC.
|
|
|
|
Post by hydrophilic on Nov 23, 2014 7:38:58 GMT
Well I sent my fast-serial routines to the official maintainer, TheUnseen (I think that's his web name). About half of my code was raw ML (like the JiffyDOS and other fast-loader code). But he wanted a pure C version of my code... I told him C is too slow on uIEC (8 MHz) and he said he has 100MHz device. Well that's great he is so much better than me, but I can't develop code on hardware I don't have.
Anyway, because I could not provide 100% C code, he never made fast-serial "official".... Strangely his "official" JiffDOS is not 100% C. Can you say DOUBLE STANDARDS? Good... I knew you could!
Anyway, you can download firmware that supports fast-serial on my website. The major problem is that it is older build -- does not support GEOS fast-loader... now that I think about it, the GEOS code is not 100% pure C either!
To be fair, he says he does not own C128, so I understand why he might be hesitant to release code he can not test. But I think it would be better to release something and then react to the feedback from users (instead of releasing nothing at all). Anyway, I don't think I would own a uIEC today if it wasn't for his work, so I still admire him.
Really, my ML code is fairly simple... mainly because I never programmed an AtMega device before I got uIEC. I imagine anybody skilled at AtMega (ML) and C programming (like TheUnseen) could easily translate between languages. I guess if he got more requests from the C128 community, he might put in that extra effort.... I'm not sure how to contact him today, but I believe the "official" firmware page is here. |
|
|
|
Post by tokra on Nov 24, 2014 15:27:20 GMT
I would for sure welcome a patch to the recent firmware. "Unseen" is active on forum64.de and has mentioned the problems with burst-mode there in several threads. If I understand correctly 1571 and 1581 behave differently to some of the same burst-commands, making things difficult. Also he has recently mentioned that the binary-"nightlies" he posts at www.sd2iec.de are tested as much as any previous version was tested. So, he just changed the naming, but now most people are still using the nearly 3 year-old 0.10.3 version as the last "official", while the nightlies have 3 years of bugfixes and improvements in them. Anyway, contact info can be found at the top of the SD2IEC-README file at www.sd2iec.de/gitweb/?p=sd2iec.git;a=blob;f=README;hb=HEADI would already be a happy camper if the ML-code hack was available for a more recent firmware version, but can live with your hack as is just fine :-) |
|
|
|
Post by hydrophilic on Nov 27, 2014 6:10:22 GMT
Thanks Tokra for your thoughtful post! I'm glad you like my hack. I don't own an REU, so I don't use GEOS much... (it is too sluggish for me without an REU). It works fantastic in C128 and CP/M modes... it also works fine for me in C64 mode, but some people report problems with a datasette attached.
I have been wanting/planning to release new firmware (that includes the recent GEOS loader), but have not because of the exact issue that you mentioned: CBM in its un-wisdom changed the way Burst Command Instruction Set (BCIS) works between the C1571 and C1581. So far I have not found a generic/compatible method to support BCIS... so I have not released any new firmware (or sent it to the Unseen).
As far as I can tell, the CMD devices (FD and HD) use the newer 1581 style, but I think that many (most?) C128 owners have a C1571... obviously true in the case of C128-D(CE) owners. The 1581, in theory, only adds the ability to support the ALMOST-NEVER-USED "partitions" (fake sub-directories).
The only positive thing about the 1581 version of BCIS is a new command "U0>Bx" (where x is 0 or 1) which will enable or disable use of the fast-serial bus. This seems to be needed for compatibility with a real C64 and Datasette (the C128 does not directly connect the Datasette line with the serial bus).
Thanks again for the links, I'll see if I can chat with him in regards to options for 1571/81/Datasette compatibility issues...
|
|
|
|
Post by hydrophilic on Dec 18, 2014 5:50:03 GMT
You know I was thinking more about a firmware update (after I finish a little project for Mirkosoft  )
However, I found a very disturbing post on Jim Brain's website:
The comment "Improve code size (to free enough space for…)" really worries me! The minimal fast-serial routines only take about 0.5K, but when you add in all BCIS stuff (U0>xx) it seems like about 1K or 2K. If space is tight, this could be a problem! So I'm thinking to fork the code... my priorities would be:
- Slow-serial: standard for all (relevant) PCs and drives
- Fast-serial: standard for late CBM drives and most (all?) CMD drives
- Disk Formats: d64, d71, d81, d2m, d4m
- GEOS: supported by several CBM and CMD drives
- JiffyDOS: requires PC upgrade (ROM); supported by most (all?) CMD drives; most CBM drives can be upgraded
- Other HW: requires PC upgrade (cartridge); supported by a few (1541/71) drives
- Other SW: supported by a few (1541/71) drives
I think #1 and #2 are most important as these are the most common in my opinion (no special software or hardware). All common disk images is #3. GEOS is #4 because it requires no special hardware, and is very popular. JiffyDOS is #5... it could be #4 except the computer MUST be upgraded (unless you use "JiffySoft" which is not reliable). Other HW is #6 and is like #5 (requires some hardware, like a cartridge). And finally #7 is the software-based stuff (which is usually limited to only 1541/71... may work with CMD devices in "compatibility mode").
Not in the list is 'other disk formats' like dpm(?) ... you know, an image of CMD-HD partition. You could also include exotic stuff like adf, d1m, g64, t64, tap, x71... I don't think the firmware could support that without sacrifice to the other # items.
So I'm hoping for some feedback from all 'disk hackers' out there... thanks!
P.S. I read somewhere that Jim Brain's uIEC uses a version of the AtMega chip which has more Flash ROM than other chips that support sd2iec... so I may be worried about nothing! In others, my firmware is primarily for uIEC... if it works for other sd2iec devices, that would be cool... but I think Jim Brain is the only developer that actually PLANNED for fast-serial support....
|
|
|
|
Post by eslapion on Sept 4, 2016 9:59:20 GMT
Was there any evolution on implementation of burst transfer rates on various SD2IEC devices ?
|
|
). It is the last official release by Commodore, but it has Y2K patches. It does not include any new features (like Jugler or ZPM).
)