Home » RBC Forums » General Discussion » Porting CP/M 68K to a repurposed ADC Soneplex MPU board (CP/M 68K)
|
|
|
|
|
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3296 is a reply to message #3293] |
Fri, 04 August 2017 11:07   |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
norwestrzh wrote on Thu, 03 August 2017 10:36Hi Plasmo,
Interesting! My 68k SBCs have operational CF, with the CPU running as fast as 12 MHz. They seem to be working fine, but I can't get the Digital Research BASIC compiler (CB68) to work reliably. I can compile something simple like:
FOR I = 1 TO 50
IF I < 5 THEN GOTO 50
IF I > 45 THEN GOTO 50
PRINT I
50 NEXT I
to compile and run OK, but not something more complex like your "ASCII art" program (I get $03 exception).
I'm wondering if you have ever tried CB68 on this platform, or one of your others? Can you get it to work?
Roger
Roger,
The "ASCII art" was produced by EhBasic which may have different syntax than CB68.
I am able to download the binary for cb68 on cpm.z80.de, but I can't find the programmer's guide for the CP/M68K version of CB68. Could you give me a quick tutorial on how to compile & run CB68 programs? I can run your short program on my board and then a longer program that didn't work for you and compare results.
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3297 is a reply to message #3296] |
Fri, 04 August 2017 16:26 |
norwestrzh
Messages: 196
Registered: November 2015
|
Senior Member |
|
|
>> The "ASCII art" was produced by EhBasic which may have different syntax than CB68.
Yes, I know. I got EhBASIC going on my 68k, and was able to benchmark the ascii.art thing (very nice trial to test out various compilers and assemblers, BTW!
>> ...but I can't find the programmer's guide for the CP/M68K version of CB68
Same here. I think I found a guide for CP/M 80 and 86, but nothing for 68k. I can tell you what I did, but given my results, I may be doing something very wrong! *grin*
Just create a file with your BASIC code, let's say "ASCII.BAS". Their BASIC compiler appears to be very flexible as far as syntax is concerned. Line numbers are only required on lines that you reference in your code, and feel free to indent and structure your code as you see fit. CB68 doesn't seem to mind.
Then:
CB68 ASCII.BAS
and:
LINK68 ASCII.O, CB68.L68
that ought to produce a .68K file that (theoretically) can be run from the command line.
[Note that CB68.L68 is (I gather) the link library for the thing.]
Thanks for looking at this. I'm *very* interested in your results!
Roger
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3298 is a reply to message #3296] |
Fri, 04 August 2017 16:31 |
norwestrzh
Messages: 196
Registered: November 2015
|
Senior Member |
|
|
>> The "ASCII art" was produced by EhBasic which may have different syntax than CB68.
Yes, I know. I got EhBASIC going on my 68k, and was able to benchmark the ascii.art thing [very nice trial to test out various compilers and assemblers, BTW!]
>> ...but I can't find the programmer's guide for the CP/M68K version of CB68
Same here. I think I found a guide for CP/M 80 and 86, but nothing for 68k. I can tell you what I did, but given my results, I may be doing something very wrong! *grin*
Just create a file with your BASIC code, let's say "ASCII.BAS". Their BASIC compiler appears to be very flexible as far as syntax is concerned. Line numbers are only required on lines that you reference in your code, and feel free to indent and structure your code as you see fit. CB68 doesn't seem to mind.
Then:
CB68 ASCII.BAS
and:
LINK68 ASCII.O, CB68.L68
that ought to produce a .68K file that (theoretically) can be run from the command line.
[Note that CB68.L68 is (I gather) the link library for the thing.]
Thanks for looking at this. I'm *very* interested in your results!
Roger
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3299 is a reply to message #3296] |
Fri, 04 August 2017 16:37 |
norwestrzh
Messages: 196
Registered: November 2015
|
Senior Member |
|
|
>> The "ASCII art" was produced by EhBasic which may have different syntax than CB68.
Yes, I know. I got EhBASIC going on my 68k, and was able to benchmark the ascii.art thing [very nice trial to test out various compilers and assemblers, BTW!]
>> ...but I can't find the programmer's guide for the CP/M68K version of CB68
Same here. I think I found a guide for CP/M 80 and 86, but nothing for 68k. I can tell you what I did, but given my results, I may be doing something very wrong! *grin*
Just create a file with your BASIC code, let's say "ASCII.BAS". Their BASIC compiler appears to be very flexible as far as syntax is concerned. Line numbers are only required on lines that you reference in your code, and feel free to indent and structure your code as you see fit. CB68 doesn't seem to mind.
Then:
CB68 ASCII.BAS
and:
LINK68 ASCII.O, CB68.L68
that ought to produce a .68K file that (theoretically) can be run from the command line.
[Note that CB68.L68 is (I gather) the link library for the thing.]
Thanks for looking at this. I'm *very* interested in your results!
Roger
|
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3301 is a reply to message #3300] |
Fri, 04 August 2017 19:07 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Roger,
Good to hear you are having problem with the website as well. I've had an intermittent internet connection last 2-3 days due to weather and I thought the problem was with my connection.
Thanks for your instruction on how to compile and run cb68.
I used EASy68K simulator to convert cb68.rel to cb68.68k and created a second flash drives, drive B, that contains cb68.68k, cb68.l68, and cb68.doc. I only have 2 meg of flash on the ADC SPX-MPU board, so I'm trying to save space. So now drive A contains CP/M 68K distribution files, drive B contains the cb68 files, and drive C is the 256K RAM drive
The next 2 screen shots shows the content of drive B, compiling your short basic program with cb68, and link it, and then run it. ( you are correct that output of the link68 is a .68k executable)
--------------------------------------
I need to change the original ascii art code so statement 110 is now:
110 if (a*a+b*b)>4 then goto 200
With that change, I'm able to compile, link, and run it. See next 2 screen shots.
It takes 104 seconds to display the ascii art. This is compiled cb68 code running on 16MHz 68302, 16-bit wide data bus and zero wait state RAM. Compare that to 102 second on 8MHz 68000 running Lee Davison's EhBasic interpreter.
|
|
|
|
|
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3307 is a reply to message #3306] |
Sat, 05 August 2017 11:25 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Roger,
The BIOS for the EASy68K simulator is same as the BIOS running in the ADC MPU board. I used EASy68K trap #15 service calls for console I/O for both BIOS. Drives A, B, C are all mapped to same areas in memory. The TPA is the same (starts at 0x20000, length of 0xA0000). So whatever I see in the simulator, I should see in the hardware. I just ran the ascii art in simulator and captured the disk image of the program from 0x20000 to 0x26000 (program is 23K). It is attached below.
Assuming your TPA starts at 0x20000, the data at location 0x205E0 should be 0x00010042 06AA0000 00010046 60D44E75 I think these information may be useful with DDT debugger, then again, I never used DDT before so I can be very wrong!
I can upload the BIOS if you are interested. I'm starting a retrobrew wiki page on the SPX-MPU board and eventually all the software will be uploaded there, but it is a work-in-progress.
https://www.retrobrewcomputers.org/doku.php?id=builderpages: plasmo:spx-mpu
Thanks for you benchmark results. The EhBASIC running on your 68k @ 12MHz is fast! By my calculation if I replace the 8Mhz with 12MHz on my 68000, the benchmark time should be 68 seconds vs your 55 seconds. That's quite a difference for running the same program. The only difference I can think is the trap #15 services for console I/O and more efficient serial port.
-
Attachment: asciiart.zip
(Size: 10.43KB, Downloaded 463 times)
|
|
|
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3313 is a reply to message #3307] |
Sat, 05 August 2017 20:43 |
norwestrzh
Messages: 196
Registered: November 2015
|
Senior Member |
|
|
Hi Plasmo --
What is that .zip file? I wanted to try it out on my SBC, but when I un-zipped it and got asciiart.bin, I discovered that it isn't a bin file at all. Seems to have some directory entries at the beginning, a Digital Research copyright embed after that, and then quite a distance down in the file, some references to ASCIIART.BAK, -.BIN, -.BAS, and -.O !! Can't figure out how to extract the goodies.
If you can generate an S-record file (SENDC68) for it, that would be great (for me anyway). Loading and running at $20000 is fine.
Thanks.
Roger
|
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3315 is a reply to message #3314] |
Sat, 05 August 2017 22:20 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Roger,
That bin file was the image of asciiart.68k when it was loaded into TPA. I thought you may have memory corruption issues (location 0x205E0 in particular), so that was a correctly working image for comparison.
It occurs to me now that perhaps the problem is not loading of asciiart.68k into TPA, but the program asciiart.68k itself. Perhaps something is wrong with link68 so the output of asciiart.68k is not correct. So attached is the zipped asciiart.68k
You mentioned that you can use s-record of asciiart.68k (as generated by sendc68). I also attach the srecord file (asciiart_srecord.txt). Out of curiosity, how do you load and execute this s-record in the CP/M environment?
Bill
---------------
Edit, I noticed you did all the compiling and linking as user 10. Have you try it as user 0?
[Updated on: Sat, 05 August 2017 22:22] Report message to a moderator |
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3320 is a reply to message #3315] |
Sun, 06 August 2017 12:08 |
norwestrzh
Messages: 196
Registered: November 2015
|
Senior Member |
|
|
Hi Bill --
Thanks for the asciiart files. I'll try them ASAP. We both use the same starting address for TPA [$20000], so I anticipate that all will be fine, but we'll see!
>> how do you load and execute this s-record in the CP/M environment?
I wrote a little program to load S-records...well, actually I swiped the S-record loader code from my monitor (modified version of the Antonakos monitor), and wrote some CP/M code around it to save the file to "disk". Want a copy? Is it permissible to post something like that here -- it is about 500 lines of code? [I feel compelled to warn you that I'm terrible at 68k assembler coding! *grin* ]
>> I noticed you did all the compiling and linking as user 10. Have you try it as user 0?
No. I used cpmtools to create that image of the filesystem, and user 10 was the first empty user area (other than user 0). So, I put it there. I could copy it elsewhere, even to an empty "disk", but I wanted to avoid the possibility of corruption during a copy. You are correct that the problem could be anywhere -- CB68, its link library (CB68.L68), or even LINK68. I'm trying to narrow down the list, so thanks again for the asciiart code. I'm hoping that it will help.
As an aside, user areas in a CP/M filesystem are really an artifice -- files that go in user 0 can be stored right alongside those in user 10. It is all one giant directory area. The only difference is the first byte of the directory entry (user 0 has that byte 0, and user 10 has an $a there), so I'm betting that the actual user area doesn't make a whole lot of difference. Hope to find out.
Roger
|
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3332 is a reply to message #3329] |
Sun, 06 August 2017 17:04 |
norwestrzh
Messages: 196
Registered: November 2015
|
Senior Member |
|
|
>> Yes, I love to have a copy of your program that saves S-record file to disk.
Here ya' go .... just remember that it *completely* ignores the address on the S-record. If your execution address is different than $20000, you are going to have to become familiar with DDT. You might have to anyway. *grin*
For example, if you upload an S-record file with code that needs to be at, say, $50000 [just for example], then you would have to start up DDT, and use the "r" command to read the file:
r<myfile>.bin
DDT will spit the starting and ending addresses of the file back at you. Then you do:
m<begin>,<end>,50000
and then start it up with:
g50000
That's assuming that you don't want to set any breakpoints.
If your file is a .68K file [i.e. it has valid headers], then use "e" instead of "r" to read it in.
Hope this helps. My apologies if you are a DDT pro (I'm not)!
Roger
P.S. I encountered a *ahem* small problem with your asciiart files. I think that your UART is at a different address than mine? Is it a 68681 DUART? At what address? Mine is at $700001. Maybe I can patch things up so that they would work?
-
Attachment: srin.s
(Size: 13.66KB, Downloaded 516 times)
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3333 is a reply to message #3332] |
Sun, 06 August 2017 17:47 |
norwestrzh
Messages: 196
Registered: November 2015
|
Senior Member |
|
|
Thinking about it, that last comment about the UART doesn't really make any sense. BASIC ought to be independent of the CONIN/CONOUT hardware, I think, and just use BIOS calls???
Here is what happens when I uploaded the .68K file you sent:
file loaded successfully.
3A>dir
A: CLIB : CLINKE SUB : CLINKF SUB : CLINK SUB : ED REL
A: LIBE A : LIBF A : LO68 REL : RELOC3 SUB : S O
A: ASCII BIN : EHBASIC BIN : STORE S : SUDOKU BIN : STORE 68K
A: SIEVE S : SIEVE 68K : SRIN S : ASCIIART BIN : SRIN 68K
A: ASCIIART 68K <== there it is
3A>asciiart
Insufficient memory or bad file header <== won't run directly
3A>ddt
********************************************************
* DDT-68K 9/20/84 Version 1.3 *
* Serial #XXXX-0000 All Rights Reserved *
* Copyright 1982,1983,1984,1985 Digital Research Inc. *
********************************************************
-rasciiart.68k <== try it as a binary file
Start = 00020000 End = 00025B7F
-g20000
Address Error at 00020806
Address Error at 001FA0B6
PC=4279001F USP=EBC22E8E SSP=0697FFFF ST=FF7C=>TR SUP IM=7 EXT NEG ZER
D 610002D4 2D40FF78 67EE206E FF780C10 002D660E 33FC0001 001FEE94 52AEFF78
A 60064279 001FEE94 206EFF78 10104880 600001BC 2EAEFF78 61000346 600001C8
Address Error at 001FBF46
Illegal Instruction at 001F814C
Address Error at 001FA1CA
?
Line 1111 Emulator at EC260000
Bus Error at 001FA1CA
[and many, many more of the same.]
3A>ddt
********************************************************
* DDT-68K 9/20/84 Version 1.3 *
* Serial #XXXX-0000 All Rights Reserved *
* Copyright 1982,1983,1984,1985 Digital Research Inc. *
********************************************************
-easciiart.68k <== try to load it as an executable file
Insufficient memory or bad file header
-
Can't even move it and run it at the *real* TPA starting address:
3A>ddt
********************************************************
* DDT-68K 9/20/84 Version 1.3 *
* Serial #XXXX-0000 All Rights Reserved *
* Copyright 1982,1983,1984,1985 Digital Research Inc. *
********************************************************
-rasciiart.68k
Start = 00020000 End = 00025B7F
-m20000,25B7F,20100
-g20100
Bus Error at 00000FFC
Address Error at 001FA0B6
PC=4279001F USP=EBC22E8E SSP=0697FFFF ST=FF7C=>TR SUP IM=7 EXT NEG ZER
D 610002D4 2D40FF78 67EE206E FF780C10 002D660E 33FC0001 001FEE94 52AEFF78
A 60064279 001FEE94 206EFF78 10104880 600001BC 2EAEFF78 61000346 600001C8
Address Error at 001FBF46
Illegal Instruction at 001F814C
Address Error at 001FA1CA
?
Line 1111 Emulator at EC260000
Bus Error at 001FA1CA
?
Line 1111 Emulator at EC260000
Bus Error at 001FA1CA
I'm disappointed.
Roger
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3337 is a reply to message #3333] |
Tue, 08 August 2017 10:53 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Roger,
I tried to run the asciiart_68k.zip that I uploaded 8/5/17 and I also experienced the same problem. That file was derived by saving the image of a disk that contains a working asciiart.68k and use cpmtools (cpmcp) to transfer asciiart.68k to my PC. I believe my disk definition file associated with cpmtools was incorrect. I made corrections and transferred asciiart.68K to my PC again. It is attached below.
I tried two methods to verify asciiart.68k:
1, I used cpmtools and copy it into a CPM disk image and execute it in CPM simulator. This works for one disk image and does not work for a different disk (the two disks have different block size and disk capacity). I'm not quite sure why.
2, Use bin2mot to convert asciiart.68k to s-record starting from 0x20000 then use your srin.s (changed the DUART address to match my hardware) to copy the s-record to CPM file then execute it. This works. I'm pretty confident the asciiart.68k is correct.
I tried sendc68 on asciiart.68k. The s-record generated starts from address 0, and is quite a bit smaller than the original asciiart.68k file in size. When I change the address offset to 0x20000 then copy to CPM using srin, the resulting file is not executable. I don't understand the purpose of sendc68, I don't think it generate the exact s-record image of the executable.
Edit: I just realize as I went through your srin.s code that it is not necessary to generate S record with address offset of 0x20000. No offset works just fine, but you already know this.
-
Attachment: asciiart.zip
(Size: 7.54KB, Downloaded 392 times)
[Updated on: Tue, 08 August 2017 12:09] Report message to a moderator |
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3340 is a reply to message #3337] |
Tue, 08 August 2017 19:39 |
norwestrzh
Messages: 196
Registered: November 2015
|
Senior Member |
|
|
Bill,
Learning new things about the strange world of CP/M 68k every day. *smile* I discovered that sendc68 skips over the CP/M 68k header. Using the Digital Research version of DUMP seems to give a true snapshot of a file. BUT, then if you grab a copy of the DUMP output, you have to have a way to convert it back to binary [and from there convert to S-record?]. I can give you a copy of a utility I wrote [pretty rude and crude] to convert a dump file back to binary. It is written in C [I run it on my Linux box], called "eatdmp". It is a little picky about the format of the dump file.
I want to be sure I understand correctly -- are you saying that, with method #2, that you can get my copy of asciiart.68k to run??
I'll try to run the latest asciiart.zip file that you uploaded -- see what happens.
As a side note, I picked up an ACC Danube router/protcol converter today at a second hand store for $5[!!!]. It contains a 68302, some flash, some DRAM [both flash and DRAM are SIMMs], and a pair of 27c010 EPROMs. Looks like there is a UART to drive a console [connection on back] and line drivers [1488/1489]. A couple of 20 MHz oscillators on board. And, of course, it has a RJ45 connection for network. I'm still trying to figure it out. It wants 24v A.C. at a little less than half an amp. Looks very clean inside. I can't believe my luck! Of course, I couldn't open it up in the store, so I just bought it on a hunch! Don't know [yet] if it works. Connectors aren't ones that I commonly use.
Roger
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3359 is a reply to message #3354] |
Tue, 22 August 2017 07:34 |
mikemac
Messages: 250
Registered: March 2017
|
Senior Member |
|
|
Nice!
plasmo wrote on Sat, 19 August 2017 10:54
When moving cursor up or down with up arrow or down arrow, don't hold down the arrow key. At high repetition rate some of the arrow key strokes are read as character inputs instead of cursor manipulation command and corrupt the data file. Use CTL-V and ESC-V to move down/up pages.
Sounds like buffer overflow on the UART. Are you sure you have HW flow control working? Years ago we had a 68K Unix system hooked up to a Beehive terminal. The function keys, including the arrow keys, send a 3 bytes escape sequence which would overflow the 1 byte buffer of the UART. Manually sending the escape sequence or using the control key equivalent would work everytime.
Mike
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3364 is a reply to message #3359] |
Tue, 22 August 2017 11:33 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Mike,
Thank you for that insight! I have no hardware flow control currently. Looking at the output of the down arrow key, I see 3-byte output, <ESC>,[, B (0x1B, 0x5B, 0x42). When down arrow key is held down, I see the character 'B' inserted intermittently in the text. So you are right, it is a case of buffer overflow. If I use Ctrl-N repeatly (equivalent to using down arrow key in microEMACS), I see no spurious text inserted. So I should either have hardware flow control or an interrupt driven console I/O.
|
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3404 is a reply to message #3374] |
Sat, 02 September 2017 11:44 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
I kludge up a IDE-CF interface board to the SPX-MPU board via the 96-pin DIN connector. The IDE-CF is driven by the 82C55 on the SPX-MPU board. The BIOS is updated with 4 more drives so drives A & B are read-only flash drives, drive C is RAM drive, drives D thru G are 8 megabyte each on IDE-CF:
A>stat dsk:
A: DRIVE CHARACTERISTICS
12,288: 128 BYTE RECORD CAPACITY
1,536: KILOBYTE DRIVE CAPACITY
256: 32 BYTE DIRECTORY ENTRIES
0: CHECKED DIRECTORY ENTRIES
128: 128 BYTE RECORDS / DIRECTORY ENTRY
16: 128 BYTE RECORDS / BLOCK
1,024: 128 BYTE RECORDS / TRACK
0: RESERVED TRACKS
B: DRIVE CHARACTERISTICS
3,072: 128 BYTE RECORD CAPACITY
384: KILOBYTE DRIVE CAPACITY
256: 32 BYTE DIRECTORY ENTRIES
0: CHECKED DIRECTORY ENTRIES
128: 128 BYTE RECORDS / DIRECTORY ENTRY
16: 128 BYTE RECORDS / BLOCK
1,024: 128 BYTE RECORDS / TRACK
12: RESERVED TRACKS
C: DRIVE CHARACTERISTICS
2,048: 128 BYTE RECORD CAPACITY
256: KILOBYTE DRIVE CAPACITY
128: 32 BYTE DIRECTORY ENTRIES
0: CHECKED DIRECTORY ENTRIES
128: 128 BYTE RECORDS / DIRECTORY ENTRY
8: 128 BYTE RECORDS / BLOCK
1,024: 128 BYTE RECORDS / TRACK
0: RESERVED TRACKS
D: DRIVE CHARACTERISTICS
64,512: 128 BYTE RECORD CAPACITY
8,064: KILOBYTE DRIVE CAPACITY
512: 32 BYTE DIRECTORY ENTRIES
0: CHECKED DIRECTORY ENTRIES
256: 128 BYTE RECORDS / DIRECTORY ENTRY
32: 128 BYTE RECORDS / BLOCK
1,024: 128 BYTE RECORDS / TRACK
1: RESERVED TRACKS
E: DRIVE CHARACTERISTICS
64,512: 128 BYTE RECORD CAPACITY
8,064: KILOBYTE DRIVE CAPACITY
512: 32 BYTE DIRECTORY ENTRIES
0: CHECKED DIRECTORY ENTRIES
256: 128 BYTE RECORDS / DIRECTORY ENTRY
32: 128 BYTE RECORDS / BLOCK
1,024: 128 BYTE RECORDS / TRACK
64: RESERVED TRACKS
F: DRIVE CHARACTERISTICS
64,512: 128 BYTE RECORD CAPACITY
8,064: KILOBYTE DRIVE CAPACITY
512: 32 BYTE DIRECTORY ENTRIES
0: CHECKED DIRECTORY ENTRIES
256: 128 BYTE RECORDS / DIRECTORY ENTRY
32: 128 BYTE RECORDS / BLOCK
1,024: 128 BYTE RECORDS / TRACK
128: RESERVED TRACKS
G: DRIVE CHARACTERISTICS
64,512: 128 BYTE RECORD CAPACITY
8,064: KILOBYTE DRIVE CAPACITY
512: 32 BYTE DIRECTORY ENTRIES
0: CHECKED DIRECTORY ENTRIES
256: 128 BYTE RECORDS / DIRECTORY ENTRY
32: 128 BYTE RECORDS / BLOCK
1,024: 128 BYTE RECORDS / TRACK
192: RESERVED TRACKS
On paper, IDE access via the 82C55 is quite slow; it takes four instructions for byte access and 5 instructions for word access; compare that to single instruction for byte or word access for bus-connected IDE interface. I did a quick benchmark of disk operation:
Pip 250K bytes of files from flash drive to RAM drive takes 3.5 seconds,
Pip 250K bytes of files from flash drive to IDE-CF takes 14.5 seconds,
Pip 250K bytes of files from IDE-CF to RAM drive takes 4.5 seconds.
So write to IDE-CF is slow, but read from IDE-CF is fairly quick compare to the RAM drive access. I think the bottleneck is in the CP/M overhead and IDE write itself. The access time of the CF registers is a small part of the overall performance.
[Updated on: Sat, 02 September 2017 11:48] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3407 is a reply to message #3406] |
Sat, 02 September 2017 18:12 |
wsm
Messages: 232
Registered: February 2017
Location: AB, Canada
|
Senior Member |
|
|
You got me kind of curious since I've played around with a couple of different flash interfaces on my 33MHz Z180 system. So far I've only been comparing relative times within this system. Using a 264K file (as reported by STAT), I got the following:
RAM disk to CF card (2GB Verbatim) : 2.8 seconds using DMA mode 2
RAM disk to serial flash chip array : 3.5 seconds using I/O instructions
Reads were harder to measure with a stopwatch ... about 1 second from CF to RAM disk.
Both interfaces used a data buffer of the appropriate size.
[Updated on: Sat, 02 September 2017 18:14] Report message to a moderator |
|
|
|
|
|
| Re: Porting CP/M 68K to a repurposed ADC Soneplex MPU board [message #3417 is a reply to message #3409] |
Mon, 04 September 2017 15:04 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
If there are interests in the repurposed SPX-MPU board for CPM-68K, I can offer boards at $20 each plus shipping ($8 in the USA). The board will have CPM-68K v1.3 distribution files installed in drive A (read only), utilities in drive B (read only), and RAMdisk in drive C (read/write). It is ready to run CPM-68K out of the box. You'll need a 5V power at 500mA, min, null modem cable for DB25, and a terminal software running at 38400 baud, 8,1,N with hardware flow controls. So far I've modified 8 SPX MPU boards successfully, 3 for my own testings, 5 to replace the SPX-MPU boards purchased on eBay that do not have large enough flash memories. I'm currently working on a CompactFlash daughter board. It is a simple design with just one 7400 IC, so I expect the pc board to be well smaller than 100mm x 100mm and costs $1.50 for the bare board. Please let me know if you are interested.
|
|
|
|
Current Time: Sat May 17 08:07:43 PDT 2025
Total time taken to generate the page: 0.01546 seconds
|
RetroBrew Computers Forum
Members
Search
Help
Login
Home
