Hi, I am just updating my PC-to-CPC transfer tool. An old project from early 90ties (I think I've never released it back then). The old version reached around 10kbytes/second transfer speed. The new one should be about twice as fast.
The thing uses a connection from PC parallel port to CPC printer port. And requires some minor modifications inside of the CPC:
- a 74LS541 chip with /OE1,/OE2 = A12,/IORD to make strobe and 7bit data bi-directional
- a wire from printer init signal to the busreset line, to allow to autostart uploaded files
- a EPROM with patched AMSDOS that redirects sector I/O to the cable
For the actual connection, you can use a standard printer cable, which fits directly to the 36pin printer port on the german 6128. For other CPCs with 34pin, or CPC+ with 25pin ports one would need to make a small adapter.
Well, at the moment I am just announcing that I am working on it. Would be nice to know if somebody is interested in that project. Please mind that it's a soldering thing, so if you can't/don't want to do soldering: Best assume that you are not interested.
I'll upload source code for the amsdos patch later. In short, the low-level transfer works like so:
init is reset from PC
strobe is clock from PC
data is 7bit data to/from PC
busy is request to PC
It's still work-in-progress. So if you have some suggestions how to improve or simplify the project, please say something.
Oh, and one important question: Does somebody know for sure if the CPC+ can/cannot output data on the busy line? The normal PPI can do that. I think that there's been some speculation the ASIC might be unable to change port b data direction - but, does somebody every verified that?
Cu, Martin
PS. patched sector I/O means that it is accessed like a floppy, ie. you can type things like
RUN"filename,
SAVE"filename,
|ERA,"*.bak
and so on, to access dsk-images on the PCs harddisk. You can also use whatever amsdos compatible file-copy software to copy files to/from the PCs harddisk to/from the real CPCs disc drive.
Hm, that's interesting... soldering shouldn't be that hard, but custom-blown EPROMs are harder to do...
Wasn't the CPC parallel port handled by the AY-3-8910? It's been a long, long time since I touched a CPC464 though - back in the 80s when I wrote Beach Head & Raid Over Moscow amongst other things.
You make me want to go see if I can pick one up now though :p
I would definitely be interested in this, and it seems a nice way of continuing on in electronics from building my first PC->CPC Parallel Cable. I have a 6128+ so wouldn't mind doing the Plus testing for this project.
What platform are you writing the PC software for? Low level stuff in Windows is difficult (directly accessing the parallel port for example), but of course this is the platform with the widest reach. I wouldn't mind using Linux though because if a project like this was a success then I would have a low end Pentium or something as a dedicated server for the CPC.
I thought blowing EPROMs was relatively simple? Can't you just connect a little adapter to PC parallel port and do it that way?
> What platform are you writing the PC software for?
I'll include the upload function in no$cpc debugger, so there'll be a windows version. And, maybe, DOS version (that version is using 16bit code, and after adding some features here and there, I am afraid that some code segments no longer fit into 64kbytes).
> Low level stuff in Windows is difficult
No problem there. Under win9x one can directly access the parallel I/O ports. Under winxp it's more difficult, especially if one doesn't have winxp (like myself). Fortunately, Sergey Anoufrienko (russian super programmer) has written a driver for no$xx, it unlocks the I/O ports, and then they can be accessed as usually. It's all working automatically - the proggy will prompt you if you want to install the driver, and thereafter you won't ever have to think about it.
> I thought blowing EPROMs was relatively simple?
Yup, EPROMs are quite simple, and FLASH chips are very simple.
You won't get around gathering some hardware: The most expensive solution is to buy an EPROM programmer. The cheapest, but most uncomfortable solution is too use an old mainboard (200MHz era or so, with BIOS in DIP sockets): Boot it, replace the BIOS by your FLASH chip while powered-on, and then write your software to it.
> Can't you just connect a little adapter to PC parallel port
That's the best (or maybe worst) solution. My own selfmade parallel port eprom burner consists of seven 74xxx chips (mainly for latching the address, data, control bits), components with plugs and sockets should be less than 5 dollars. Only problem is wiring the chips by hand can easily take some days :-)
> I would definitely be interested in this... I have a 6128+
> so wouldn't mind doing the Plus testing for this project.
Would be great!
Can you test if the printer BUSY signal can be reconfigured as output? For example,
ld bc,0f780h
out (c),c ;set direction to output
ld b,0f5h
ld a,0ffh
lop:
out (c),a ;output busy bit
xor a,40h
jr lop
Pinouts are here, http://cpcwiki.eu/index.php/Connector:Printer_port, BUSY is Pin11 on either CPC and CPC+.
If the test program works okay then Pin11 should output a square wave. Which could be seen with an oscilloscope, or, if you have only a multimeter: you should see around 2.5V DC on that pin.
If it doesn't work, then you'd probably get a permanent 5V high level.
Quote from: nocash on 22:50, 20 March 10
Fortunately, Sergey Anoufrienko (russian super programmer) has written a driver for no$xx, it unlocks the I/O ports, and then they can be accessed as usually. It's all working automatically - the proggy will prompt you if you want to install the driver, and thereafter you won't ever have to think about it.
This sounds great. I have seen some DLL libraries (such as this one (http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html) and this one (http://home.comcast.net/~hardandsoftware/ionet.htm)) for accessing the parallel port in XP and later whilst I was researching the idea of writing a Windows version of Turbo Transfer. But if you have one already written then that's even better.
Quote from: nocash on 22:50, 20 March 10
The cheapest, but most uncomfortable solution is too use an old mainboard (200MHz era or so, with BIOS in DIP sockets): Boot it, replace the BIOS by your FLASH chip while powered-on, and then write your software to it.
What a fantastic idea. I have exactly that - an old P200 mainboard, so will have to dig it out and see if it's suitable. I guess you just use the mainboard's flash update utility and replace the update with the image you want to write?
Quote from: nocash on 23:05, 20 March 10
Can you test if the printer BUSY signal can be reconfigured as output? For example,
I have a multimeter so will try this on my 6128+ when I get home tomorrow and let you know.
Quote from: WinterMute on 15:44, 20 March 10
Wasn't the CPC parallel port handled by the AY-3-8910? It's been a long, long time since I touched a CPC464 though - back in the 80s when I wrote Beach Head & Raid Over Moscow amongst other things.
You make me want to go see if I can pick one up now though :p
Sorry no. the Ay handled the keyboard.
The parallel port uses a 74ls latch chip.
Quote from: nocash on 19:52, 19 March 10
Oh, and one important question: Does somebody know for sure if the CPC+ can/cannot output data on the busy line? The normal PPI can do that. I think that there's been some speculation the ASIC might be unable to change port b data direction - but, does somebody every verified that?
I did test this and I don't think the ASIC "PPI" can change it, but then I didn't actually test the signal on the parallel port, I just tested it through programming.
Quote from: nocash on 23:05, 20 March 10
If the test program works okay then Pin11 should output a square wave. Which could be seen with an oscilloscope, or, if you have only a multimeter: you should see around 2.5V DC on that pin.
If it doesn't work, then you'd probably get a permanent 5V high level.
I had to change the hex syntax in the program to assemble properly in WinAPE/Maxam (hope I got it right):
org &8000
ld bc,&f780
out (c),c ;set direction to output
ld b,&f5
ld a,&ff
lop: out (c),a ;output busy bit
xor a,&40
jr lop
Appears it did not work - I got a constant 5v whether I was running the program or not on my 6128+.
Would it be possible as a start to patch AMSDOS to work with the current Parallel Cable (http://www.cpctech.org.uk/docs/mods/parallel.html) (because I've already made one of these ;) )...?
Got the overall send/receive byte procs back working with the new version. Sending /STROBE from PC to CPC didn't work. On my old PC it worked fine, but my current PC seems to have a weaker /STROBE signal, and it can't pull-down the /STROBE from the CPC (which is set high by software).
Okay... so I've replaced it by /AUTOLF. Now the schematic looks like so:
____________
| 74LS541 |
/IORD ---------|/OE1 D0..6|----- DATA0..6
A12 ---------|/OE2 D7|----- /AUTOLF (instead of /STROBE)
D0..7 ---------|Q0..7 |
|____________|
/BUS RESET ----------------------- /INIT
Meaning that one would need to disconnect the /AUTOLF pin from the mainboard (in CPC it's wired to GND, in CPC+ to 5V). According to Kevin's printer cable doc the GNDing didn't worked well anyways; the doc recommended to leave that pin unconnected. So, disconnecting it should still stay compatible with normal printers, hope so!
> [busy-output] Appears it did not work - I got a constant 5v
Too bad. On normal CPC it's working great. And on CPC+...
One could latch BUSY externally with a 74LS74 chip, but the port decoding (A11=0, A9=1, A8=0, /IOWR=0) would be a bit complicated.
Another idea would be to use the strobe output (that from the CPC, not from the PC), and wire it to /ACK. So the CPC could send data requests via STROBE, and the PC would see them as ACK.
That should work fine for the transfer. But when connecting a real printer to the CPC, the printer may not work (if it outputs something on ACK, and drags the CPCs strobe to whatever state... :-/
Any better ideas?
> work with the current Parallel Cable
I think that's really too slow to be of any use.
Quote from: nocash on 22:32, 22 March 10
> [busy-output] Appears it did not work - I got a constant 5v
Too bad. On normal CPC it's working great. And on CPC+...
Tell me about it, I was really looking forward to this project.
Quote from: nocash on 19:52, 19 March 10
Oh, and one important question: Does somebody know for sure if the CPC+ can/cannot output data on the busy line? The normal PPI can do that. I think that there's been some speculation the ASIC might be unable to change port b data direction - but, does somebody every verified that?
Do you have a link to this - I take it from your comments that it's been discussed somewhere before? I'd like to read about it after my discovery today...
The info (or speculation) on the emulated PPI in the CPC+ is here: http://www.cpctech.org.uk/docs/cpcplus.html since you didn't get BUSY pulsed, it seems to be correct about port B and C being fixed-directional on the CPC+.
Meanwhile, the sector loading is working again (though only with system discs yet, will be still some work to support data format, and error handling, etc.) Anyways CAT and LOAD and RUN are working. Loading a 16K file takes 1-2 seconds :-( maybe some reasons of the slow transfer can be blamed on AMSDOS, which relocates the sectors after loading.
Plus, booting the CPC takes 1-2 seconds, too. Damn, Amstrad. Couldn't they see that a Z80 is WAYS too slow to zerofill 42 kilobytes of RAM? Booting & transfer makes the "instant-autoboot" idea more a "please-be-patient-boot". Anyways, it should be still faster than loading from real disk drives.
For the request signal from CPC to PC, I'll probably drop BUSY, and use the strobe bit wired to ACK (or maybe better SLCT or so?). If you add a logic gate between STROBE and ACK, it'll become one-way, so ACK from printer can't creep to STROBE. On the CPC+ that requires less components than trying to latch BUSY externally. Though it's a pity to need to use that workaround as the original CPCs would work without that trick.
Hi Nocash,
sounds like an interesting project, especially if it would work with USB/Parallel adapters (my PC doesn't have a parallel port anymore). I'm not too sure about all the hardware changes that need to be made inside the CPC though. A lot of CPC users would be reluctant to mess about inside their hardware, no? Have you considered using the Joystick inputs for PC->CPC data and the printer port for CPC->PC data? Obviously the cable is more complicated, but it would negate the need for internal modifications. Another option might be to access the CPC directly through the expansion port, it's bi-directional and could be accessed faster if the PC was simply mapped to an address.
Just my thoughts on the hardware side, what do you think?
Bryce.
Quote from: Bryce on 10:33, 23 March 10
Hi Nocash,
sounds like an interesting project, especially if it would work with USB/Parallel adapters (my PC doesn't have a parallel port anymore). I'm not too sure about all the hardware changes that need to be made inside the CPC though. A lot of CPC users would be reluctant to mess about inside their hardware, no? Have you considered using the Joystick inputs for PC->CPC data and the printer port for CPC->PC data? Obviously the cable is more complicated, but it would negate the need for internal modifications. Another option might be to access the CPC directly through the expansion port, it's bi-directional and could be accessed faster if the PC was simply mapped to an address.
Just my thoughts on the hardware side, what do you think?
Bryce.
I too was thinking the joystick port may be a good solution on the cpc+ too.
But then I thought, it would be great to have a real USB like cable for the CPC, but then the software would be more difficult.
The reason for USB anyway is that I have not always been successful using the parallel cable with a PC, and Bryce's point is valid for these new pcs.
What about a PIC connected to the expansion port, it could decode the I/O address and act like a buffer??
I too am thinking about low cost solutions..
I like it that the amsdos functions are redirected and you can download direct into the cpc, because it would make it a really good way to test cpc software.
Well I think a lot of the project could be adapted too for other cables...
I think this is a good project. Please continue.
The software isn't all that difficult, I had intended putting together a "real" USB connection to the CPC, but I have very little time at the moment, so I never got around to it. I'm not much of a PC programmer, I can do it, but it wouldn't be pretty :) but I'd be willing to do the hardware, if someone else writes the software for both ends.
Bryce.
Nocash; Why's it called an XBoo cable? Sounds like something for an XBox.
Hi Bryce
> if it would work with USB/Parallel adapters
Probably not. I would assume that those adapater work only for printers, not for general-purpose things where one would control the strobe/busy/ack signals directly via I/O ports... Theoretically, protected mode drivers *could* trap accesses to parallel I/O ports, and *could* forward them via USB... but I would doubt that existing drivers do support such thungs.
> my PC doesn't have a parallel port anymore
Horror! :-)
> lot of CPC users would be reluctant to mess about inside their hardware, no?
Pretty sure. Myself, I'd prefer internal mods, it can't get lost once when it's in there.
> using the Joystick inputs for PC->CPC data
> and the printer port for CPC->PC data?
Joystick port only would be nice, too. But it lacks GND, and on the CPC+ most pins are input-only. Both joystick+printer port would be too many messy connectors... And for autoboot, one would even need a third connector for /BUS RESET on expansion port :-)
> access the CPC directly through the expansion port
Currently, I am aiming towards not using the PPI's busy. Instead, everything goes through port EFxxh. So, yeah, if preferred, it'd be relative easy to make an external expansion port adaptor. Unlike the internal variant, it'd also need to include the 74273 that latches the printer output.
Cu, Martin
Hi Kevin
> I have not always been successful using the parallel cable with a PC
Mine will be super-stable :-) as long as the PC does have a parallel port. Actually, it must be a bidirectional one, but I think one-directional ports haven't been manufactured since around 1992, so that should be no problem.
> What about a PIC connected to the expansion port
It'd only need to handle reads/writes to port EFxxh, so an expansion port adaptor could be compatible with the internal mod. Making an external adaptor would require four or five 74xxx chips, so it may be easier to use a single PIC or PAL chip here. Though then you'd need tools for programming that chip, and if it should be a SMD chip you could forget about doing the wiring by hand. Altogether, I'd like it best to need only 1-2 standard 74xxx chips.
> I like it that the amsdos functions are redirected and
> you can download direct into the cpc, because it would
> make it a really good way to test cpc software.
Yup, I've used it for testing/rev-engineering.
> a lot of the project could be adapted too for other cables...
> would be great to have a real USB like cable for the CPC
Yeah... USB would be nice, too. I never got around to learn how the USB protocol works. I guess once when one is familar with it, it'll turn out to be pretty simple. Does somebody have some sample code for it? Something like how to send "Hello Test" to the PC.
As far as I know, USB can be programmed in software on PICs... though I've no idea if one does need a PIC... theoretically, it could be also programmed in software on the Z80 itself - or are there some minimum timing requirements, making the Z80 too slow to do that?
PS. No, xboo has nothing to do with xbox. There's no good reason for the name. It comes from a similar project for GBA, it was originally called boot.asm, then I made a modified version called xboo.asm, with the x being for extended or experimental, and then I somehow got stuck with that name... and also used it for NDS and PSX parallel port cables.
USB hardware interfacing is a lot trickier than simple discrete i/o or RS232 interfacing, but it's worth the effort, there are several ways to interface to USB:
a) Use a purpose built USB controller/stack such as the FTDI / Vinculum range. These have everything you need ready to use and can communicate with your project through RS232 commands. Advantage is that you could probably even connect a Z80 to USB with it, dis-advantage they only come in SMD packages, so not very "hobbiest friendly" and they're not the cheapest solution.
b) Simulate the USB stack in a standard PIC/Atmel MCU. Has been done, but it's more bother than it's worth as far as I'm concerned. Simulating the USB interface in a Z80 would probably mean the Z80 would be too busy to do anything else while connected and may get bogged down if the data stream is too fast.
c) Use a PIC/Atmel MCU with built in USB connectivity. There are several available even in standard DIL packaging. Not sure about the Atmel parts, but the Microchip PICs have Drivers / Stack software and sample data online to aid development. And they're not too expensive, the 18F4550 used in the SDCard Floppy emulator has full USB support and cost around €4 - €5.
Bryce.
Found some source here, http://www.waitingforfriday.com/index.php/Building_a_PIC18F_USB_device - it's allowing to read a push-button, and to control a led. Sounds like a nice & simple example... But, the source code is 310K bytes in size. Imagine that, 310K for toggling a LED on and off! I think, I'll stay with the trusty centronics port. Unless... the 4-5 euro chip, is that easier to use?
---
Oh, and for the GX4000, basically, the cable should work on it, too. The RUN"FILENAME commandline is transferred via cable, so it can load the disk image without needing a keyboard, and of course without needing a FDC. But, once and when, I've heard that the GX4000 would be incompatible with the CPC+, is that true?
As far as I remember, somebody told me that inserting the CPC+ System Cartrige into the GX4000 would result in a "LINE DOES NOT EXIST" error message or so. What is causing that? Looking at the schematics, the only significant difference between CPC+ and GX4000 is that LK5 isn't connected. As far as known, LK5 should swap rom0 and rom7, so when it isn't connected, both BASIC and AMSDOS would be unstable. That would explain compatibility problems... On the other hand, looking at the photo of the GX4000 mainboard (see cpcwiki gallery), it seems as if LK5 is GNDed.
One more question: Does somebody know how AMSDOS clones are accessing double-sided disks?
All AMSDOS clones seem to support the standard read/write sector commands, RSX names chr(84h/85h), with AMSDOS style parameters C=sector, D=track, E=drive. The problem here is that AMSDOS doesn't define a parameter for the head number. Is there some kind of a standard how AMSDOS clones define the head?
It might be to assigned as E=head/unit (eg. with bit2=head, as it is internally handled by the FDC itself), or encoded in D=track/head, or it might be not implement at all in that RSX commands. And in worst case all AMSDOS clones may handle it differently :-)
At the moment I am only patching the normal, single-sided AMSDOS. Anyways, if there is a standard for double-sided BIOSes, it'd be great to know about it!
The Chip used on the "Waiting for Friday" link you posted IS the 4-5€ PIC I mentioned, which is also used in the SD Card Floppy Emulator.
The 310K zip includes all the includes and libraries that are supplied by Microchip so you don't have to write these yourself, plus his LED code with comments. All of this is in uncompiled text form, so the actual program would be a lot shorter. His actual code for the LEDs is only a few lines long. Unfortunately, this is what scares people away from using USB from the very beginning. But as I mentioned earlier, yes, it's a heck of a lot more complicated than discrete i/o or RS232, but it also has some major (speed / compatibility) advantages.
Bryce.
> The Chip used on the "Waiting for Friday" link you posted IS the 4-5€ PIC
Igitt, that WAS the solution where the hardware does handle the USB transfer... and one still needs 310K source code? Yep, the main file is small, but if one needs all the other lib/include stuff, then... I don't like it.
My own experiences with USB are that one can be glad if it works. It took me some years to find a working generic driver for usb mass storage devices. So I wouldn't give it too many compatibility points.
The parallel transfer is working okay now. Read/write sector, with data/system format. Only, I still need to decide which signals to use instead of BUSY...
The "source" could be STROBE or /STROBE. The uninverted STROBE would be best to avoid conflicts with the PC pulling /STROBE high. Downside is that the CPC+ doesn't have STROBE, only /STROBE, so then one would need an extra inverter for it.
And the "destination"... PE, BUSY, /ACK, /ERROR, SLCT... maybe /ERROR would be best, with normal printer operation it should be always HIGH, so there's less risk that it could pulldown (/)STROBE. But, /ERROR is on the bottom-side of the mainboard... for soldering it'd be easier to connect everything to the upper pins... then SLCT would be better... I think it's defaulting to HIGH level, too. Except when the printer goes offline.
Uh, if I use STROBE and SLCT... then SLCT=LOW would pull-down STROBE only when the printer is offline, and in that situation STROBE should be LOW anyways, since one can't send data while the printer is offline. Does that sound like a good idea?
Quote from: nocash on 21:33, 23 March 10
It might be to assigned as E=head/unit (eg. with bit2=head, as it is internally handled by the FDC itself), or encoded in D=track/head, or it might be not implement at all in that RSX commands. And in worst case all AMSDOS clones may handle it differently :-)
Apart from Vortex, of which I have very little knowledge, AMSDOS "clones" such as ParaDOS, ROMDOS, S-DOS etc all use D = cylinder * 2 + head. ie. Track 0 is Cyl 0, Head 0, Track 1 is Cyl 0, Head 1, Track 2 is Cyl 1, Head 0 etc.
> D = cylinder * 2 + head
Thanks! Ahhh, is that true? I think a lot of programs are using the read sector RSX command with "D=cylinder" for accessing the normal single-sided 3" drive. Compatibility with that programs would be blown-up when using "D=cylinder*2+head".
Don't understand how that could work... unless the DOS autodetects if drive A and B are SS or DS... or gives them hardcoded assignments like A=SS, B=DS... but that won't work with "abba" switches that swap A / B.
Quote from: nocash on 12:27, 31 March 10
Thanks! Ahhh, is that true? I think a lot of programs are using the read sector RSX command with "D=cylinder" for accessing the normal single-sided 3" drive. Compatibility with that programs would be blown-up when using "D=cylinder*2+head".
D simply has a range of 0..79 (for 40 track) or 0..159 (for 80 track) rather than just 0..39. ParaDOS etc replaces the cylinder and head used in the commands with the correct values.
Quote
Don't understand how that could work... unless the DOS autodetects if drive A and B are SS or DS... or gives them hardcoded assignments like A=SS, B=DS... but that won't work with "abba" switches that swap A / B.
Depending on the ROM, the drives are either hard-coded for 40/80 and SS/DS, set up (eg. using ParaDOS Drive Definition Byte), or the cylinders and sided-ness are determined by the format (eg. ROMDOS D20 is automatically assumed to be 80 track, double-sided). ParaDOS reads sector ID's to determine the format. Installing an ABBA switch may confuse things when ROMDOS/ParaDOS formats aren't used.
Quote from: nocash on 21:14, 23 March 10
Oh, and for the GX4000, basically, the cable should work on it, too. The RUN"FILENAME commandline is transferred via cable, so it can load the disk image without needing a keyboard, and of course without needing a FDC. But, once and when, I've heard that the GX4000 would be incompatible with the CPC+, is that true?
As far as I remember, somebody told me that inserting the CPC+ System Cartrige into the GX4000 would result in a "LINE DOES NOT EXIST" error message or so. What is causing that? Looking at the schematics, the only significant difference between CPC+ and GX4000 is that LK5 isn't connected. As far as known, LK5 should swap rom0 and rom7, so when it isn't connected, both BASIC and AMSDOS would be unstable. That would explain compatibility problems... On the other hand, looking at the photo of the GX4000 mainboard (see cpcwiki gallery), it seems as if LK5 is GNDed.
I have uploaded 2 pictures. One showing the system cartridge inserted, second showing the result.
I used 2 system cartridges, yellow label and green label and the result was the same.
Both showed "v4".
As you can see it has a Ready prompt, but no BASIC reported. Pressing the fire buttons and joypad buttons causes chars to be printed.
Sometimes when turning on it gives errors such as "line does not exist" or "file not found", and sometimes extra chars are printed, but I think it was from bad connections this time.
EDIT: Disabling the disc rom via emulation gives the same result, but I don't really know if this is what is actually happening. i.e. it doesn't appear at rom position 0 or 7. I wish I had an eprom programmer :(
Quote from: Executioner on 01:34, 01 April 10Depending on the ROM, the drives are either hard-coded for 40/80 and SS/DS, set up (eg. using ParaDOS Drive Definition Byte)
BTW is there a definition of all values these two bytes (&BAFE and &BAFF) can take (besides figuring them out from the source (http://www.winape.net/download/ParaDOS_src.zip) of course, as even http://www.grimware.org/doku.php/documentations/software/parados/manual.v1.0 (http://www.grimware.org/doku.php/documentations/software/parados/manual.v1.0) just says things like "specialised option, if you don't know what it means, you don't need it!" - where giving an explanation would arguably have taken just as little space ;) )?
These two bytes seem to survive a reset! From a first look at the mapping (counting from 0 as the LSB), bit 2 apparently indicates the head and bit 3 double-stepping...
> As you can see it has a Ready prompt, but no BASIC reported.
Great to know... that sounds a lot like ROM-bank problem... I just got the same effect in my emu when changing the LD C,7 at 05EBh to LD C,0 (so the bootmenu jump goes to the BASIC bank, instead of the AMSDOS bank). The result is no BASIC 1.X displayed (as you said), no DISC functions (only TAPE), and BASIC is working (one can enter commands, and programs with line numbers). And, the memory isn't cleared, for example:
10 PRINT"HELLO
CALL 0
LIST
despite of the CALL 0, the PRINT line can be still LISTed. If there are other uninitialized memory regions... that might also explain 'Line does not exist' errors.
Looking at the photo of the GX4000 mainboard with the LK5 (ASIC pin 119) wiring. It seems to be going to a GNDed region - but it isn't - it's only going to a dirt-free region; that isn't covered by the brown solder fluid. Instead it seems to continue on the solder side, as far as I can see it's going somewhere near Q5.
Can somebody check that on a real GX4000 mainboard? Where does ASIC pin 119 go to?
The schematic says not connected, but on the photo there seems to be wire connected to it?
EDIT: If you are there, you may want to disconnect it from whereever it connects to, and wire it to GND (as in CPC+), that should prevent the bank 0/7 swapping, and the bootmenu should be shown as on CPC+. Of course, without keyboard, you can't select any options (instead, burning rubber should start automatically after 15 seconds).
Quote from: OCT on 14:47, 06 April 10
BTW is there a definition of all values these two bytes (&BAFE and &BAFF) can take ...
There is a file distributed with WinAPE I think called pdos-ddb.txt. Here's the contents of that file:
ParaDOS uses a locking technique to reset the drive definitions to their default values when the CPC
gets reset. There is a slight possibility that some programs may confuse the locking system, but that
should be rare.
The lock works by placing the bytes #53 and #44 at address #BAFA and #BAFB respectively (ie.
"PD", short for ParaDOS). If these two bytes are intact, it is assumed that the bytes at addresses
#BAFC and #BAFD respectively are also intact, and these are used as the master copy of the DDB
and DPB (Drive Definition Byte and Drive Parameter Byte).
The values that are actually used to determine the number or tracks, number of sides, default side
and stepping mode are stored in the DDB at #BAFF. The byte at #BAFE determines the format
preference for DATA, SYSTEM and IBM formats. These two bytes are copied from #BAFC and
#BAFD on reset if the lock is intact. This allows a user-defined setting to be used, which will survive
through resets as long as the lock survives (for example, type |DRIVE, and configure the drive
settings. When you reset all the settings remain intact).
The actual values for the DDB are as follows:
Drive A:
---------
bit 7 - Head use when single-sided (Normally 0)
bit 6 - Single stepping (0) or double-stepping (1).
bit 5 - Number of tracks per side (0 = 40, 1 = 80)
bit 4 - Number of sides, single-sided (0) or double-sided (1).
Drive B:
---------
bit 3 - Head use when single-sided (Normally 0)
bit 2 - Single stepping (0) or double-stepping (1).
bit 1 - Number of tracks per side (0 = 40, 1 = 80)
bit 0 - Number of sides, single-sided (0) or double-sided (1).
The DPB bits are as follows:
Bit 3 - (0) Disable, (1)Enable Ultraform format rather than ROMDOS D10 (*Config says D1)
Bit 2 - (0) Disable, (1)Enable IBM format rather than ROMDOS D1 (*Config says D10).
Bit 1 - (0) Disable, (1)Enable extended DATA and SYSTEM formats (Electro Formats)
Bit 0 - Drive configuration (DDB) usage affected by formats. (0 = Unlocked, 1 = Locked)
The Format setup menu in ParaDOS has ROMDOS D10 and ROMDOS D1 switched in the menu.
So to make a temporary change to the drive definition, poke &baff or &bafe with the new value. To
make a semi-permanent change, poke &bafd or &bafc and the corresponding byte at &baff or
&bafe. To make a permanent change, change to ROM at address #1c00 (DDB) or #1c03 (DPB).
The correct default values for 40 track, single-sided drive B should be 0 and 0.
I personally use DDB=#03 (80 track, double-sided drive B) and DPB=#02 (Electro formats
enabled).
To allow 80 track, double-sided discs to be used in Drive B: use DDB=#03. Disabling Electro
formats allows 40 track, single-sided DATA and SYSTEM format discs to be used in drive B:
Great to have BAFxh bytes described on the Parados page!
> D simply has a range of 0..79 (for 40 track) or 0..159 (for 80 track)
> the drives are either hard-coded for 40/80 and SS/DS,
> or the cylinders and sided-ness are determined by the format
Okay, I see... Makes sense from the file-systems point of view. Downside is that one cannot access the 2nd side when the file-system "thinks" that disk is single sided.
An example would be the Orion Prime disk (which has the "loader" portion formatted as single-sided 40 tracks, but also uses the second side and upper 40 tracks). The game is using I/O instead of RSX, so the RSX restriction doesn't cause problems there.
---
Another thing: I have solved the GX4000 question without having a GX4000 mainboard! A relative good picture of the PCB is hidden in the service manual. The pin119 connection I've (believed to have) seen on the photo turned out to be pin118. Whilst pin118 is not connected at all - just as it was shown in the schematics.
So, rom bank 0 and bank 7 cannot be used on the GX4000. Unlike as in the CPC+, there isn't even a pull-up on pin119, so one can't even trust the pin to be in a stable high state (which should swap the banks, as far as known).
At hardware side, a simple workaround would be to wire the pin to GND. Thereafter, AMSDOS and BASIC should be stable. As far as I know, nobody has verified that yet, so I am only 99% sure here. There's a minimal chance that pin119 affects only the PPI input, not the ROM banking. Though, most probably it affects both.
At software side it'd be more difficult. One would need a couple of patches for the bank switching code. I'll make an updated no$cart version, that should (hopefully) allow to run DSK images on GX4000.
Quote from: nocash on 19:22, 09 April 10
Okay, I see... Makes sense from the file-systems point of view. Downside is that one cannot access the 2nd side when the file-system "thinks" that disk is single sided.
It's a little bit more complicated than that. The formats store information in what's called a DPB. The DPB (XDPB) determines the number of blocks and heads for a particular format. ParaDOS then uses the DPB to determine which heads to use. The DPB gets set up after ParaDOS does the Read ID processing that AMSDOS normally does to detect System/Data/IBM format, slighltly modified. (This is all from memory, I'd have to double-check the source code).
Quote from: Executioner on 03:19, 11 April 10
It's a little bit more complicated than that. The formats store information in what's called a DPB. The DPB (XDPB) determines the number of blocks and heads for a particular format. ParaDOS then uses the DPB to determine which heads to use. The DPB gets set up after ParaDOS does the Read ID processing that AMSDOS normally does to detect System/Data/IBM format, slighltly modified. (This is all from memory, I'd have to double-check the source code).
yes, and working a little with cpcxfs there are different ways that cpm uses to decide when to access the 2nd side:
One method is this:
track 0 side 0, track 0 side 1, track 1 side 0, track 1 side 1.. etc
Not sure of name.
Another is:
track 0 side 0, track 1 side 0... track 39 side 0, track 0 side 1, track 1 side 1
I think this one is called "cylinders".
And another is:
track 0 side 0, track 1 side 0... track 39 side 0, track 39 side 1, track 38 side 1
I think this one is called "eagle".
All from memory, cpcxfs has more info in it.