Author Topic: xboo cable  (Read 10292 times)

0 Members and 1 Guest are viewing this topic.

Offline nocash

  • 464 Plus
  • *****
  • Posts: 352
  • Liked: 0
Re: xboo cable
« Reply #25 on: 14:27, 31 March 10 »
> 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.

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 390
Re: xboo cable
« Reply #26 on: 03:34, 01 April 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.

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.331
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2240
Re: xboo cable
« Reply #27 on: 15:15, 06 April 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 :(
« Last Edit: 16:53, 06 April 10 by arnoldemu »
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Offline OCT

  • 464 Plus
  • *****
  • Posts: 349
  • Liked: 42
ParaDOS Drive Definition Byte(s)
« Reply #28 on: 16:47, 06 April 10 »
Depending 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 of course, as even 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...
« Last Edit: 16:50, 06 April 10 by OCT »

Offline nocash

  • 464 Plus
  • *****
  • Posts: 352
  • Liked: 0
Re: xboo cable
« Reply #29 on: 17:02, 06 April 10 »
> 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).
« Last Edit: 17:11, 06 April 10 by nocash »

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 390
Re: ParaDOS Drive Definition Byte(s)
« Reply #30 on: 03:40, 07 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:

Code: [Select]
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:

Offline nocash

  • 464 Plus
  • *****
  • Posts: 352
  • Liked: 0
Re: xboo cable
« Reply #31 on: 21:22, 09 April 10 »
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.

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 390
Re: xboo cable
« Reply #32 on: 05:19, 11 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).

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.331
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2240
Re: xboo cable
« Reply #33 on: 11:36, 12 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.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource