Native C development on RC2014
414 views
Skip to first unread message
Robert Kincaid
Aug 5, 2021, 3:47:32 PM8/5/21
to RC2014-Z80
In case it's useful to folks, I thought I'd share my recent experience doing native, on-board C development with an RC2014 platform.
I'm primarily a Mac user so I wanted a Mac-based equivalent to Grant Searle's FilePackage.exe utility. I got a C-based command-line working on MacOS and thought: gee I wonder if I could get this working natively on my somewhat minimal SBC114/MissingModule system. So I went down the rabbit hole of doing C development on an RC2014 class system....
I tried various compilers. I wanted Aztec C to work as I had experience back in the day with that on my Apple II and even with an early 80's corporate gig (Xerox) for an MS-DOS based commercial product (long story...). Unfortunately BOTH Aztec C and Hi-Tech C showed bad stability issues with the code I was compiling. Things would mostly work fine but then suddenly the disk I was working on would just go blank or have garbage directory entries. At first I thought it was a bad CF card or worse my system was broken. But I ran Steve Cousins CF diagnostic and it wrote and formatted every single sector on the card just fine. It pushed the system so hard I got my first warm chip (the 6850 on the MissingModule). I now suspect that the compiler and/or assembler on both systems were blowing out the TPA and tramping on the OS that trashed the CF in some way. Note that the source code is really not very large, so I'm not sure what the issue is. And I never got an error that anything was about to go wrong. But of course it is C after all *grin*.
Then I tried BDS-C. Night and day difference! In retrospect I like this system much better than Aztec (particularly for CP/M development). Things have been quite stable with no problems whatsoever. It's also VERY fast and efficient due to most things happening in-memory vs temporary disk files.
The bonus result (and what folks might be most interested in) is that I have a single source file that compiles on the Mac natively (not cross-compiled) using Xcode/clang (which is old school K&R compliant) and BDS-C on CP/M. I can compile the same code for multiple platforms. I presume (but haven't tried yet) that I should be able to use clang on Linux and maybe even Windows. This is nice because I can do rapid development under Xcode with symbolic debugging, breakpoints, single-stepping, etc. and then copy over to the SC114 to compile for CP/M (or of course I could use an emulator but what's the fun in that *grin*). The only catch is you have to write your C K&R 80's style and avoid the temptation to use all the stdlib API's that came later.
Now finally, you might ask what's the point of a packager under CP/M. What I wanted to be able to do was easily create PKG images of disks I had set up "just the way I want them" and have an easy way to restore this setup on a fresh CF card or a new system. This all seems to work now. I was able to natively package my A: drive and use depkg.com to drop the whole shebang onto another drive (just as a test).
I'm still optimizing the code and dealing with some corner cases on filename differences between CP/M and other OS's (i.e. convert any incoming file paths to a single 8.3 CP/M compatible filename). When I'm reasonably comfortable that it's stable I'll put the source and binaries out on GitHub in case anyone else finds it useful. No commitment on an ETA.
Finally, if you read this far good for you. It was an interesting process all around as I realized I was truly reliving some of the experience of back in that day where C code would just blow up for no reason and the tools were funky and the API's limited and you had to actually hand-code some stuff vs. reusing things off the internet. No click-and-fix IDE's etc. Consequently even the frustrations were kind of fun (in retrospect) and I know a lot more about my CP/M system and how download and FilePackage.exe works.
- Robert
Bill Shen
Aug 5, 2021, 11:54:07 PM8/5/21
to RC2014-Z80
You may have an underlying CF disk problem that's being masked by using a compiler that stores temporary data in memory rather than in temporary disk files. I like you to check the integrity of your CF disk with a simple test:
pip d:=a:*.*[v]
This assumes drive D is for temporary storage and drive A contains many files (you may use other drives more suitable for this test). The verify switch compares copied files to the original files. It is a quick and easy way to check the integrity of CF disk .
Bill
Robert Kincaid
Aug 6, 2021, 1:40:16 AM8/6/21
to RC2014-Z80
pip d:=a:*.*[v] works just fine.
I suppose it's possible that the diagnostic itself initialized some sectors that had might have had marginal formatting and maybe fixed some low level problem. I might try reinstalling Aztec and see if it still acts up, but I'm loath to have to reinitialize my CF card if it goes bad again. Although I have a card reader I can use to just dd the 128Mb onto my Mac for a quick restore. So next time I have time to experiment I'll give it a try.
A mystery...
Robert
Robert Kincaid
Aug 9, 2021, 1:56:08 AM8/9/21
to RC2014-Z80
Update if anybody is interested...
Well, I ordered a new card of the exact company and size (128MB). And... It works with Aztec C just fine. I dd'd a copy of the working card and dd'd it back to the old card and gave the old card another try. And yep, the old card still fails randomly.
So apparently the old card has some issue and Bill guessed correctly, but it seems to ONLY show up when I'm compiling C code on Aztec or Hi-Tech C. At least so far - and even though the old card passes various diagnostics and responds to dd transfers just fine. So whatever isn't right must be subtle and maybe when there's too many fast read/writes happening during a compile. Go figure. As Bill mentioned, BDS's in-memory compile probably avoids this issue, and it must not be a memory issue or overrunning the BIOS or BDOS. And at least my soldering skills aren't to blame *grin*.
Anyway, it seems Aztec is good to go (although requires some minor code changes from BDS). I have tried Hi-Tech yet, but I imagine it will work on the new card too.
Sort of an authentic 80's experience, huh? *grin*. We didn't have CF cards back then, but we did have strange compiler and hardware issues at times... One time we even had to drag out the ICE machine (if you know what I mean...).
The good news is that my portable packaging tool works, and I can probably make it compile on clang AND the three compilers I've tried so far on CP/M.
I guess I should just shell out the bucks for an industrial CF card next time...
Alan Cox
Aug 9, 2021, 8:08:15 AM8/9/21
to rc201...@googlegroups.com
Sort of an authentic 80's experience, huh? *grin*. We didn't have CF cards back then, but we did have strange compiler and hardware issues at times... One time we even had to drag out the ICE machine (if you know what I mean...).The good news is that my portable packaging tool works, and I can probably make it compile on clang AND the three compilers I've tried so far on CP/M.I guess I should just shell out the bucks for an industrial CF card next time...
It doesn't seem to be about being industrial rather that you need an old design card. The industrial cards just tend to lag a bit so the old Cisco branded cards and similar types with prehistoric flash controllers do rather better. The newer ones are designed for high speed DMA interfaces so have extremely sharp edges which don't do well on a long bus and also test the power supply and distribution rather more. Putting the CF next to the CPU seems to help a bit, using the PPIDE card so you have a proper I/O interface fixes the problem properly and lets you use real spinny rust as well. You can even get reverse SATA-PATA adapters so you can plug one of those into the PPIDE and a SATA drive into that.
One test is to try reading and writing big files full of alternating 0x00/0xFF 0xF0/0xF and 0xAA/0x55 pairs so you maximise the stress on the signal lines.
Hi-Tech C is surprisingly nice. Maximum size per source file is a bit constrained and you need a large TPA but it's fairly close to full ANSI C (and slightly pre-dates it - it's from the K&R "Apocrypha" edition). The output is Z80 however so it is not portable across all CP/M systems.
Alan
Bill Shen
Aug 9, 2021, 6:33:16 PM8/9/21
to RC2014-Z80
The suspected problem is what Alan had said: fast edge driving loaded bus with data pattern sensitive (reading 0xFF is particularly problematic). Normally running PIP with verify is a quick and sure test of this problem, but there is a more extensive test by Cube Central you can try. The discussion about Cube Central's CF test is here:
https://groups.google.com/g/linc80/c/hk6MB8bfs8o/m/vQhU54L6EQAJ
I attached mm84.bas for you to try in CP/M using MBASIC80. The command in CP/M is
mbasic80 mm84.bas
You'll see an initial test followed by write/verify of random size files to your CF disk. The files will have extension .MMM so you can easily erase them all after the test.
Bill
PS, another possibility is your CF disk has mechanical intermittent problems where insertion and extraction of CF disk can cause the problem to come and go. Try to wiggle your boards while running the test.
https://groups.google.com/g/linc80/c/hk6MB8bfs8o/m/vQhU54L6EQAJ
I attached mm84.bas for you to try in CP/M using MBASIC80. The command in CP/M is
mbasic80 mm84.bas
You'll see an initial test followed by write/verify of random size files to your CF disk. The files will have extension .MMM so you can easily erase them all after the test.
Bill
PS, another possibility is your CF disk has mechanical intermittent problems where insertion and extraction of CF disk can cause the problem to come and go. Try to wiggle your boards while running the test.
Robert Kincaid
Aug 9, 2021, 10:00:31 PM8/9/21
to RC2014-Z80
Thanks for the followup. I'll give the new diagnostics a try on the problematic card and see what happens.
My new card (same make/model) seems to be keeping up (so far). But do I understand I should really look for a vintage card for ultimate reliability? Ideally a NOS Cisco card or equivalent?
The most disappointing thing is that if fails in a rather significant way without any indication of a failure. Ugh! That could be a CP/M BIOS/BDOS issue, but I suspect it's more a card firmware issue. Sigh...
I appreciate the continued help.
Thanks,
Robert
Alan Cox
Aug 9, 2021, 10:10:25 PM8/9/21
to rc201...@googlegroups.com
On Tue, 10 Aug 2021 at 03:00, Robert Kincaid <rhki...@gmail.com> wrote:
Thanks for the followup. I'll give the new diagnostics a try on the problematic card and see what happens.My new card (same make/model) seems to be keeping up (so far). But do I understand I should really look for a vintage card for ultimate reliability? Ideally a NOS Cisco card or equivalent?The most disappointing thing is that if fails in a rather significant way without any indication of a failure. Ugh! That could be a CP/M BIOS/BDOS issue, but I suspect it's more a card firmware issue. Sigh...
The CF interface simply assumes the bus is reliable. There are no checksums or error handling except for data bursts in Ultra-DMA mode which we don't do - way beyond anyything RC2014 can handle! In normal modes CF is basically just an ISA bus subset. It wasn't until SATA that IDE/ATA style drives got proper CRC checks on the bus. So if your bus is borked you just get crap to or from the disk.
Alan
PauldB
Aug 10, 2021, 6:15:57 PM8/10/21
to RC2014-Z80
Bill, that's an amazing coincidence that you should post your 10e CF Module modification just now. I hadn't seen that before in the retro groups.
I realize that this is slightly off topic, but I thought some feedback on Bill's engineering mod could be useful.
I've been trying to get a stock 10f CF Module (very similar to Bill's 10e board) to to read *or* write anything but cr*p using a known working CF card. I had expected these results as I had been corresponding with Karl (a neighbor of mine, or rather from Norway, the neighboring country just west of Sweden ;)) and, as a way to get my stagnant brain back into electronics, thought I could use some of his early CF boards for testing.
I was studying your SIMPLE80 and RIZ180 schematics just yesterday to see how you had designed the IDE44 interface. I saw you had added a 100R resistor in series with the /RD signal and 100pF capacitor from /RD (on IDE44) to GND, presumably to add a small delay.
I had soldered in the modification last night, although as the CF adapter is just piggybacked (not soldered - oh, and thanks for the tip earlier) onto the CF board, so my mod was a bit different.
Today I did some testing with very good results so far. No errors doing variations on 'pip j:=b:*.*[v]' and 'unzip pi.zip' (Phillip's nice PI archive).
I'm running a 2nd CF module (RC2014 modified for IO=0x20) along with the 10f CF module (also Karl's '63b Z80 & Serial Module' (@20MHz) and his '65a ROM/RAM Module' on 'BackPlaneFour'). So I thought of a more interesting test.
assign shows:
A:=MD0:0
B:=MD1:0
C:=IDE0:0
D:=IDE0:1
E:=IDE0:2
F:=IDE0:3
G:=IDE2:0
H:=IDE2:1
I:=IDE2:2
J:=IDE2:3
Make a copy of a slice on the 10f board (C:) to a slice on the RC2014 board (J:), with verification:
C>PIP J:=C:*.*[V]
COPYING -
DDTZ.DOC
CPM.SYS
Success!
The summaries from 'DIRX' showed:
C:
58 File(s), occupying 632K of 8176K total capacity
380 directory entries and 6992K bytes remain on C:
J:
58 File(s), occupying 632K of 8176K total capacity
452 directory entries and 7544K bytes remain on J:
Looks good so far. More testing needed...
I should add that I had made a few more changes to the 10f PCB.
I connected GND to IDE44 pins 40 & 43 and soldered a 100uF capacitor in parallel with the onboard 100nF capacitor.
The CF cards I've tested so far are 'pre-owned' 64MB InnoDisk and 64MB PQI cards.
Paul
Robert Kincaid
Aug 10, 2021, 7:29:48 PM8/10/21
to RC2014-Z80
Here's my setup. An SC114, at #61i Missing Module from Karl sitting in my own design 3d printed tray (so no shorts on the bottom). There are two more RC2014 bus headers behind the board, but nothing is in them. Note that this is the "I" revision. So the layout is different from the previous boards. Also, I'm pretty sure Karl is aware of the mods folks have done and I believe this board may already include them (note the new rows of resistors and a couple of caps near the CF card). I don't have a schematic, and I'm not sure Karl has posted it yet. The solder on the 40 pin header for the CF card is actually a bit better than the reflections indicate. Read below for more info...
Some things to note:
1. I've only EVER seen a failure while compiling Aztec or Hi-Tech C. Today I even got the failure just compiling the example program so I'm now convinced it's not due to me doing something weird in my own C code.
2. The failure exhibits as the directory getting trashed. It will either fully populated with blank filenames and ":" separators when I do a dir, or occasionally some of the files will show up but be empty or corrupted. So it looks like it trashes the entire directory in some fashion.
3. So far every single diagnostic has not shown any errors. Steve Cousins' CF diagnostic reads and verify all sectors, the BASIC program Bill provided has run successfully so far. Here's where it is right now:
W>D:YL211.MMM V<D:YL211.MMM C>B:YL211.MMM V<B:YL211.MMM 5504.13 20267
W>D:KX212.MMM V<D:KX212.MMM C>A:KX212.MMM V<A:KX212.MMM 5556.31 20267
W>B:DR213.MMM V<B:DR213.MMM C>C:DR213.MMM V<C:DR213.MMM 5608.72 20267
W>D:VR214.MMM V<D:VR214.MMM C>C:VR214.MMM V<C:VR214.MMM 5661.39 20267
W>C:UT215.MMM V<C:UT215.MMM C>B:UT215.MMM V<B:UT215.MMM 5714.3 20267
W>C:SE216.MMM V<C:SE216.MMM C>D:SE216.MMM V<D:SE216.MMM 5767.45 20267
W>C:LO217.MMM V<C:LO217.MMM C>A:LO217.MMM V<A:LO217.MMM 5820.86 20267
W>C:HJ218.MMM V<C:HJ218.MMM C>B:HJ218.MMM V<B:HJ218.MMM.
Note that I set it up for all 16 partitions, so it's writing/verify A: through P: That's the only change I made to the code so let me know if I should stick to 4 partitions are can try something else. If I interpret the output correctly I'm coming up on almost 6MB of read/writes so far? However note that the last column I think is the length of what was written and I'm seeing a bit of variance there. Is that normal? It started with 20271, when to 20269 and is now 20267.
QUESTION: Does the BASIC program come to a final end point or does it just run forever. At this point its been goin on for about 2-3 hrs. What should I expect to happen besides error reports (and when)?
4. I've also been able to do raw read/writes to both the problematic and working boards boards with dd on MacOS without mishap. This is using a USB/CF adaptor.
5. I HAVE NOT had any problems with the other CF card I purchase which is identical (in theory) to this one. Same product off Amazon.
6. Later I may give the board a good flux clean just to make sure something subtle there is gettin in the way. You would think that would affect both boards, but who knows...
Other than the C compiler issues, the system has worked flawlessly so far. To bad there isn't an equivalent of NPR's "The Car Guys" for computer issues *grin*.
Robert
PS The case/tray is on thingiverse If anybody wants to make one.
Robert Kincaid
Aug 10, 2021, 7:40:45 PM8/10/21
to RC2014-Z80
Sorry for the second post. I realized there is a schematic for the #61i included with the build instructions. And it does indeed look like the new resistor/cap section includes something similar to the fix mentioned. I'm reluctant to publicly post the schematic myself before Karl does in case he didn't intend this to be widely distributed just yet. However, there is a cap across !IORD/GND and another between !IOWR/GND.
Bill Shen
Aug 10, 2021, 11:07:16 PM8/10/21
to RC2014-Z80
Robert,
The mm84.bas program will run continuously until you hit a CTRL-C or turn off the power. It will eventually crash when it ran out of disk space.
Your #61i Missing Module indeed has the recommended 8 terminating resistors for data lines and 100ohm/100pf filter for CF read strobe. Karl also added a 100ohm/100pF filter for CF write strobe, but that's generally not a problem area.
Since your troublesome CF passed PIP with verify, Steve Cousin's CF test and now the MM84 test, I no longer feel it is a "fast edge driving loaded bus with data pattern sensitivity" problem. It is something else.
Steve Cousin's CF diagnostic includes a CF identification feature. Have you compare the CF ID of both your disks?
When I read you've 16 drives, A: to P:, each 8 megabytes, my thought is 128meg CF disk is actually smaller than 128meg; typically the last drive is quite a bit smaller than 8 meg. To muddy the water more, I have a few CF disks that are labelled 128Meg, but is actually 64meg. I'm now wondering how your CF disk is formatted, and if it is smaller than 128meg what's the effects of putting 16 partitions on disk that doesn't have the needed space.
I afraid I have questions and no answers at this point.
Bill
Bill Shen
Aug 10, 2021, 11:13:04 PM8/10/21
to RC2014-Z80
PauldB,
I'm glad the 100ohm/100pF filtering is working out for you. The filtering has the most impact with proper operations of CF disks, but it does not fix ALL CF disks; you'll still have problems with some brands of CF disks. In Simple80 and RIZ180, I also add delays to CF read and write strobes from CF chip_select. Ideally, the delay should be 50-60nS, but most CF disks can work with much less delay. The 3 fixes for proper CF access are 1), 60nS setup time from CF_chip_select valid to CF_read and CF_write strobes; 2), filter of CF_read strobe signal with 100ohm/100pF RC filter; 3), source termination of CF data bus with 100 ohms resistors.
In my experience "PIF with verify" is the quickest way of checking proper CF operations.
Bill
Robert Kincaid
Aug 11, 2021, 12:40:14 AM8/11/21
to RC2014-Z80
@Bill Shen
Yep, it ran until disk full. No errors. ended at 12877.1 KB. I did not remove the exiting files on the CF card (not a huge amount) so they chewed up some space already so it might have terminated a bit prematurely than it might have otherwise. However, the drive on which I was compiling was clean since I had to do an era *.* to clean out the buggy directory entries. An "ls.com" program I have reports:
169 File(s), occupying 7460K of 8176K total capacity
198 directory entries and 716K bytes remain on C:
so it was pretty full and much fuller than I ever got it compiling.
I'll check the CF info tomorrow and get back. You are correct however that drive P is a bit smaller. But I wasn't doing any activity on P when I had the issue.
Thanks again for helping troubleshoot.
Robert
Robert Kincaid
Aug 11, 2021, 1:30:02 PM8/11/21
to RC2014-Z80
Well... Here's some news... First, Steve's Small Computer Workshop package also includes a CF Information tool. It dumps more than just what the diagnostic does. And... While the cards appear to be identical and have identical labels they apparently are NOT identical - although they came from the same amazon vendor a week or so apart. Oh China what have you done *grin*. But these were really cheap so I guess lesson learned. On the other hand, I learned some stuff so it wasn't all a waste of time.
*IF* the good card really is "SMART CF", it *might* be really good though. A quick search for "SMART CF" shows some industrial cards by that name that include S.M.A.R.T. reporting, so that would be a generation better than the older 2005 card. Maybe... Again just a guess.
And to be fair, based on my experience of the flaky card only blowing up during a compile, I suspect the flaky card would work fine for simple camera storage and it probably did pass whatever manufacturing test (if any) they performed.
Here are the details:
Flaky Card:
-----------------
Compact flash card test v0.4 by Stephen C Cousins
Number of sectors on card: $0003D400
Compact flash card information v0.4 by Stephen C Cousins
Number of sectors on card: $0003D400
Card size: 128MB
Card model: "STI Flash 7.2.0 "
Serial number: "TS I1Jd0012609902574"
Firmware version: "04.29.05"
Default number of cylinders: $03D4
Default number of heads: $0008
Default sectors per track: $0020
Card's self diagnostic test passed
===============================================
Good card:
-----------------
Compact flash card information v0.4 by Stephen C Cousins
Number of sectors on card: $0003D400
Card size: 128MB
Card model: "SMART CF "
Serial number: " S PT8184H1V2"
Firmware version: "20100924"
Default number of cylinders: $03D4
Default number of heads: $0008
Default sectors per track: $0020
Card's self diagnostic test passed
Reply all
Reply to author
Forward
0 new messages