Is BD-DOS lost to time?
Is BD-DOS lost to time?
BD-DOS, for the Byte Drive 500, is mentioned on the Wikipedia Oric page and reported on non-Oric forums as though it were primarily an Oric device. It appears in photographic form in CEO-Mag #272.
Has anyone preserved BD-DOS and/or any technical information for potential emulation?
Has anyone preserved BD-DOS and/or any technical information for potential emulation?
Re: Is BD-DOS lost to time?
Maybe the simplest would be to contact the guy on the forum post you linked.
Apparently the two authors of the Byte Drive 500 are Paul Simpson and Peter Halford working at Tyrell Computers, which happens to match at least one person on Linked In: https://www.linkedin.com/in/paul-simpson-23910112/
Apparently the two authors of the Byte Drive 500 are Paul Simpson and Peter Halford working at Tyrell Computers, which happens to match at least one person on Linked In: https://www.linkedin.com/in/paul-simpson-23910112/
Re: Is BD-DOS lost to time?
Probably the actual easiest thing for answering these sort of questions for myself would be to learn French.
Pulling on that thread there seem to be articles in both CEO-Mag #154 and 155. So a quick subscription to that is probably the best plan.
Pulling on that thread there seem to be articles in both CEO-Mag #154 and 155. So a quick subscription to that is probably the best plan.
Re: Is BD-DOS lost to time?
Attached is ZIP file with Euphoric emulator configured with Byte Drive 500 ROM and auto-booting bddos.dsk.
I run it with DosBox under Linux:
Code: Select all
cd euphoric
dosbox -conf euphoric.conf
Actually I played shortly with the DOS and I'm really impressed and I like it!
So, if anyone can provide more technical info about used I/O space, RAM Ovl switch, etc. - it will be very helpful and we can add support in Oricutron and CLK Signal .
- Attachments
-
- euphoric-bddos.zip
- (259.24 KiB) Downloaded 368 times
Re: Is BD-DOS lost to time?
Fantastic, amazing! I'm sure we can figure it out from the ROM and a disk image.
Given that the intention of the Byte Disk was to be the disk drive for every platform, showing only the relevant files on each, it might also be fun to try to figure out the on-disk format. There's possibly non-Oric versions of BD-DOS on that disk too.
EDIT: other than 6502 vectors, this is a complete disassembly of the ROM, by the way:
Vectors are NMI -> $022b, reset -> 0xe000, IRQ -> 0228, for the record. So guesses:
One further quick observation before bed: the supplied disk is an MFM_DISK but appears to use longer-than-usual tracks. For now I'm detecting this by just not truncating any sector that is in-progress when you hit the 6250 byte mark. I guess if there's only one BD-DOS disk image in existence then whether to think of that as a rule is somewhat moot. But otherwise I was truncating sector 11, leading inevitably to a portion of nonsense and a CRC error when reading.
I have so far implemented:
As an aside, tying the head load request directly to the head loaded input might work on real drives; mine still reach their proper velocity instantaneously so I declined to do that because then sectors will be loaded before they're signalling ready, which causes BD-DOS to enter a temporary retry loop in its boot ROM and a perpetual one in its boot sector. As long as a real drive takes at least two revolutions to reach full speed I don't think that should be an issue (and these are reputedly 5.25" drives, so we're talking a real physical index hole, not a virtual one, meaning it'll signal even at low speeds).
Given that the intention of the Byte Disk was to be the disk drive for every platform, showing only the relevant files on each, it might also be fun to try to figure out the on-disk format. There's possibly non-Oric versions of BD-DOS on that disk too.
EDIT: other than 6502 vectors, this is a complete disassembly of the ROM, by the way:
Code: Select all
E000 78 SEI ; Disable interrupts.
E001 A9 08 LDA #$08
E003 8D 20 03 STA $0320 ; Store 8 to $0320; assuming that to be a WD command
; register, that's a restore, with either:
;
; no spin-up sequence, if a WD177x; or
; a set head-load request and wait for head load response, if a 179x.
;
; => a 179x, almost certainly, with a Microdisc-esque capacity to switch the
; motor on upon a head load request, and indicate head loaded in response.
E006 2C 12 03 BIT $0312 ; Loop until bit 6 of $0312 is set. Bit 6 of $0312 is the WD's IRQ line,
E009 50 FB BVC $E006 ; and this is waiting for end of operation.
E00B AD 20 03 LDA $0320 ; Read WD status.
E00E A2 00 LDX #$00 ; Set output pointer to 0.
E010 A9 01 LDA #$01
E012 8D 22 03 STA $0322 ; Store 1 to WD sector register.
E015 A9 80 LDA #$80
E017 8D 20 03 STA $0320 ; Store $80 to WD command register. That's read sector, no initial delay,
E01A 2C 12 03 BIT $0312 ; Check IRQ and DRQ outputs from the WD.
E01D 70 10 BVS $E02F ; If the command has finished, jump off to E02F.
E01F 10 F9 BPL $E01A ; If there's not yet any more data to read, repeat the status read.
E021 AD 23 03 LDA $0323 ; Read the next byte.
E024 9D 00 04 STA $0400,X ; Store to $400 + X
E027 E8 INX ; Increment X.
E028 4C 1A E0 JMP $E01A ; Go back to polling.
E02B EA NOP
E02C EA NOP
E02D EA NOP
E02E EA NOP
E02F AD 20 03 LDA $0320
E032 29 9C AND #$9C ; If the drive is signalling not ready, sector 1 wasn't found,
E034 D0 DF BNE $E015 ; it had a CRC error, or data was lost in transfer, try the read again.
E036 4C 00 04 JMP $0400 ; Otherwise, branch to $400.
; i.e. Read sector 1 from track 0, which may be at most 256 bytes long, to $400,
; and execute it. If it doesn't load, retry until it does.
;
; Assuming a classic 5.25" drive, the ready signal implies motor on + two index holes passed.
; So it can be used approximately to evaluate completion of spin-up. If they shipped an
; IBM PC-style drive it'd instead indicate that the head had stepped and the disk had not been
; ejected since. We can probably assume the former, as a restore won't necessarily step the
; head — if it's already at track 0 then no motion will occur. So it's not really an indicator of
; anything in this code.
- * the ROM is paged at startup; and
* it's possibly incompatible with BASIC 1.1 (motivation for guess: it duplicates the 1.0 IRQ and NMI vectors, which differ from the 1.1).
Code: Select all
* = 0400
0400 2C 11 03 BIT $0311
0403 2C 17 03 BIT $0317
0406 A9 1A LDA #$1A
0408 8D 80 BB STA $BB80
040B A9 00 LDA #$00
040D A0 68 LDY #$68
040F 85 60 STA $60
0411 84 61 STY $61
0413 A9 01 LDA #$01
0415 2C A9 00 BIT $00A9
0418 2C A9 07 BIT $07A9
041B AA TAX
041C 48 PHA
041D 49 01 EOR #$01
041F 29 03 AND #$03
0421 8D 23 03 STA $0323
0424 A9 13 LDA #$13
0426 8D 20 03 STA $0320
0429 2C 12 03 BIT $0312
042C 50 FB BVC $0429
042E AD 20 03 LDA $0320
0431 A0 FF LDY #$FF
0433 E6 39 INC $39
0435 E6 39 INC $39
0437 88 DEY
0438 D0 F9 BNE $0433
043A BD E0 04 LDA $04E0,X
043D 8D 22 03 STA $0322
0440 A0 00 LDY #$00
0442 A9 80 LDA #$80
0444 8D 20 03 STA $0320
0447 2C 12 03 BIT $0312
044A 70 12 BVS $045E
044C 10 F9 BPL $0447
044E AD 23 03 LDA $0323
0451 91 60 STA ($60),Y
0453 C8 INY
0454 D0 F1 BNE $0447
0456 E6 61 INC $61
0458 4C 47 04 JMP $0447
045B 4C 00 04 JMP $0400
045E AD 20 03 LDA $0320
0461 29 9C AND #$9C
0463 D0 F6 BNE $045B
0465 E8 INX
0466 68 PLA
0467 48 PHA
0468 C9 07 CMP #$07
046A D0 04 BNE $0470
046C E0 0A CPX #$0A
046E B0 04 BCS $0474
0470 E0 0B CPX #$0B
0472 90 C6 BCC $043A
0474 68 PLA
0475 F0 A2 BEQ $0419
0477 C9 01 CMP #$01
0479 F0 9B BEQ $0416
047B 78 SEI
047C D8 CLD
047D A2 FF LDX #$FF
047F 9A TXS
0480 AD 80 03 LDA $0380
0483 A0 00 LDY #$00
0485 98 TYA
0486 99 00 00 STA $0000,Y
0489 99 00 02 STA $0200,Y
048C 99 37 98 STA $9837,Y
048F C8 INY
0490 D0 F4 BNE $0486
0492 20 1C 95 JSR $951C
0495 A9 0C LDA #$0C
0497 20 D4 96 JSR $96D4
049A 20 2E 6C JSR $6C2E
049D 20 44 6F JSR $6F44
04A0 B0 B9 BCS $045B
04A2 20 0A 96 JSR $960A
04A5 AD 01 C0 LDA $C001
04A8 C9 59 CMP #$59
04AA F0 16 BEQ $04C2
04AC 20 B2 68 JSR $68B2
04AF A9 03 LDA #$03
04B1 20 B8 73 JSR $73B8
04B4 90 0A BCC $04C0
04B6 A9 EB LDA #$EB
04B8 A0 04 LDY #$04
04BA 20 0C 73 JSR $730C
04BD 4C 7B 04 JMP $047B
04C0 A9 00 LDA #$00
04C2 8D FD 97 STA $97FD
04C5 A2 02 LDX #$02
04C7 BD DD 04 LDA $04DD,X
04CA 9D 05 E9 STA $E905,X
04CD A9 3F LDA #$3F
04CF 9D E0 02 STA $02E0,X
04D2 CA DEX
04D3 10 F2 BPL $04C7
04D5 A9 60 LDA #$60
04D7 8D 09 F4 STA $F409
04DA 4C 00 C0 JMP $C000
04DD 4C 00 68 JMP $6800
04E0 01 03 ORA ($03,X)
04E2 05 07 ORA $07
04E4 09 0B ORA #$0B
04E6 02 ???
04E7 04 ???
04E8 06 08 ASL $08
04EA 0A ASL A
04EB 07 ???
04EC 2A ROL A
04ED 45 52 EOR $52
04EF 52 ???
04F0 2D 4E 4F AND $4F4E
04F3 20 43 4F JSR $4F43
04F6 4D 2E 2A EOR $2A2E
04F9 3F ???
04FA 0D 0A 00 ORA $000A
04FD D4 ???
04FE C5 C5 CMP $C5
0500 .END
I have so far implemented:
- a WD1973;
- with motors tied to a head load request, but head loaded signalled only when a drive is signalling ready.
As an aside, tying the head load request directly to the head loaded input might work on real drives; mine still reach their proper velocity instantaneously so I declined to do that because then sectors will be loaded before they're signalling ready, which causes BD-DOS to enter a temporary retry loop in its boot ROM and a perpetual one in its boot sector. As long as a real drive takes at least two revolutions to reach full speed I don't think that should be an issue (and these are reputedly 5.25" drives, so we're talking a real physical index hole, not a virtual one, meaning it'll signal even at low speeds).
Re: Is BD-DOS lost to time?
Fabrice's notes are a little vague on what accesses other than to the WD do (at least when read through automated translation), so I am brute-forcing the problem, with slightly weird results.
Per Fabrice, the accesses other than to the WD are probably to Apple/Pravetz-esque soft switches. I seemed to find accesses to $310, $313, $314 and $317 to be most prevalent, and decided that probably they equate to two addresses that enable or disable overlay RAM, and two addresses that enable or disable the Byte Drive ROM.
If those guesses are accurate then that gives 24 possible arrangements between switches and functions. Not too many to brute force.
Surprise! More than one arrangement therein seems to give a working BD-DOS. I haven't yet been thorough enough to spot the commonalities and differences between those that work and those that don't.
In the meantime, here's that disk's 'RUN ME':
Per Fabrice, the accesses other than to the WD are probably to Apple/Pravetz-esque soft switches. I seemed to find accesses to $310, $313, $314 and $317 to be most prevalent, and decided that probably they equate to two addresses that enable or disable overlay RAM, and two addresses that enable or disable the Byte Drive ROM.
If those guesses are accurate then that gives 24 possible arrangements between switches and functions. Not too many to brute force.
Surprise! More than one arrangement therein seems to give a working BD-DOS. I haven't yet been thorough enough to spot the commonalities and differences between those that work and those that don't.
In the meantime, here's that disk's 'RUN ME':
Re: Is BD-DOS lost to time?
Further notes, probably the final for today:
The boot sector accesses $0311 and $0317 only. It has a check for BASIC 1.0 (at 04a5–04aa in the disassembly above). Therefore either $0311 or $0317 must disable the disk ROM, and the other must do something else. It seems safe to respond to either and ignore the other. Definitely neither enables overlay RAM.
Using $0313 to enable overlay RAM and $0310 to disable it certainly seems to be sufficient to get to the boot prompt.
It strikes me now that there may well be no means to re-enable the disk ROM, as it doesn't do anything useful once the machine is booted.
Further reading on the Byte Drive 500 reveals it usually came with a 3" drive, though I did find at least one instance of it for sale with a 5.25" drive.
The bottom of a directory listing says 'DR0 282 sectors free'. So the interface likely supports multiple drives. Between that and the 5.25" drive version, it is possible that some of the other accesses select drive and/or disk side. I could find no way to change drive.
The supplied sample disk is single sided and 40 tracks.
One article I found suggested that the team behind the Byte Drive had licensed CP/M and were planning to offer that in some capacity for some machines. It's therefore also possible that some of the switches control single/double density mode.
When booting normally, the real Oric is careful to put itself into PAL mode. BD-DOS makes no such attempt. So there is a risk of restarting in NTSC mode, depending on memory contents after reset.
I don't yet have a complete concept of the logic behind motor control, but since the boot ROM loads a sector without touching any of the presumed soft switches, we can assume it's automatic.
EDIT: as per its announcement thread, I've thrown out a version of my emulator that implements behaviour as above. I strongly suspect there's a lot more to learn here though.
The boot sector accesses $0311 and $0317 only. It has a check for BASIC 1.0 (at 04a5–04aa in the disassembly above). Therefore either $0311 or $0317 must disable the disk ROM, and the other must do something else. It seems safe to respond to either and ignore the other. Definitely neither enables overlay RAM.
Using $0313 to enable overlay RAM and $0310 to disable it certainly seems to be sufficient to get to the boot prompt.
It strikes me now that there may well be no means to re-enable the disk ROM, as it doesn't do anything useful once the machine is booted.
Further reading on the Byte Drive 500 reveals it usually came with a 3" drive, though I did find at least one instance of it for sale with a 5.25" drive.
The bottom of a directory listing says 'DR0 282 sectors free'. So the interface likely supports multiple drives. Between that and the 5.25" drive version, it is possible that some of the other accesses select drive and/or disk side. I could find no way to change drive.
The supplied sample disk is single sided and 40 tracks.
One article I found suggested that the team behind the Byte Drive had licensed CP/M and were planning to offer that in some capacity for some machines. It's therefore also possible that some of the switches control single/double density mode.
When booting normally, the real Oric is careful to put itself into PAL mode. BD-DOS makes no such attempt. So there is a risk of restarting in NTSC mode, depending on memory contents after reset.
I don't yet have a complete concept of the logic behind motor control, but since the boot ROM loads a sector without touching any of the presumed soft switches, we can assume it's automatic.
EDIT: as per its announcement thread, I've thrown out a version of my emulator that implements behaviour as above. I strongly suspect there's a lot more to learn here though.
Re: Is BD-DOS lost to time?
Some more quick observations on this, relevant to yesterday's botched release:
The boot ROM performs: seek to 0, read boot sector, check for errors (including drive not ready).
Somewhere between then and the command prompt, the logic changes to: (i) issue a force interrupt and check for drive not ready; (ii) only if drive is ready, issue fetch.
My understanding of Shugart RDY is that it goes active when the disk is spinning and two index holes have passed, and inactive when the motor is off. I decided to check some old Shugart OEM manuals. Frustratingly they pretty much all tell you that's correct for RDY becoming active, and decline to comment on if/when it'll go inactive again.
In the optional 'disk change' output section they state that the disk change output will be active "if while deselected the drive has gone from a ready to a Not Ready (Door Open) condition". Though elsewhere it is strongly implied that they expect users to have the motor on permanently so I'm not sure what to read into that.
They also mention a 'ready modified' jumper with which "the Ready Circuit is modified so that the drive will stay ready" (specifically because single-sided drives definitely otherwise set ready to false if you try to use the second side, so that option is supposed to let you check sidedness without losing RDY).
Therefore I've currently no completely compelling answer as to when the Byte Drive 500's drive is expected to signal RDY. I've gone with a variant of the modified scheme above — RDY will be set after initial motor on and after two index holes have passed. It will be reset only if the disk is ejected.
That causes BD-DOS fully to function.
The boot ROM performs: seek to 0, read boot sector, check for errors (including drive not ready).
Somewhere between then and the command prompt, the logic changes to: (i) issue a force interrupt and check for drive not ready; (ii) only if drive is ready, issue fetch.
My understanding of Shugart RDY is that it goes active when the disk is spinning and two index holes have passed, and inactive when the motor is off. I decided to check some old Shugart OEM manuals. Frustratingly they pretty much all tell you that's correct for RDY becoming active, and decline to comment on if/when it'll go inactive again.
In the optional 'disk change' output section they state that the disk change output will be active "if while deselected the drive has gone from a ready to a Not Ready (Door Open) condition". Though elsewhere it is strongly implied that they expect users to have the motor on permanently so I'm not sure what to read into that.
They also mention a 'ready modified' jumper with which "the Ready Circuit is modified so that the drive will stay ready" (specifically because single-sided drives definitely otherwise set ready to false if you try to use the second side, so that option is supposed to let you check sidedness without losing RDY).
Therefore I've currently no completely compelling answer as to when the Byte Drive 500's drive is expected to signal RDY. I've gone with a variant of the modified scheme above — RDY will be set after initial motor on and after two index holes have passed. It will be reset only if the disk is ejected.
That causes BD-DOS fully to function.
Re: Is BD-DOS lost to time?
Partial disassembly of the boot sector:
Code: Select all
* = 0400
0400 2C 11 03 BIT $0311 ; Unknown purpose.
0403 2C 17 03 BIT $0317 ; Unknown purpose.
0406 A9 1A LDA #$1A
0408 8D 80 BB STA $BB80 ; $BB80 = $1A
040B A9 00 LDA #$00
040D A0 68 LDY #$68
040F 85 60 STA $60
0411 84 61 STY $61 ; ($60).w = $6800; this is where data from disk will be loaded to.
0413 A9 01 LDA #$01
0415 2C A9 00 BIT $00A9 ; Unknown purpose.
0418 2C A9 07 BIT $07A9 ; Unknown purpose.
041B AA TAX ; X seems to be a current track counter; seed it to 1.
041C 48 PHA ; Also put $01 on the stack, as a current sector pointer.
041D 49 01 EOR #$01
041F 29 03 AND #$03
0421 8D 23 03 STA $0323 ; Store (a ^ 1)&3 to the WD data register — seek tracks in ascending order despite the descending variable.
0424 A9 13 LDA #$13
0426 8D 20 03 STA $0320 ; Begin command $13, i.e. a seek to track (a ^ 1)&3
0429 2C 12 03 BIT $0312
042C 50 FB BVC $0429 ; Wait until command is finished.
042E AD 20 03 LDA $0320 ; Read the status (to clear the interrupt bit?)
0431 A0 FF LDY #$FF ; Y = $ff
0433 E6 39 INC $39
0435 E6 39 INC $39 ; Perform $39 += 2, 255 times. At completion: Y = 0, $39 is 2 higher.
0437 88 DEY ; $39 is not used elsewhere, so this is likely just a wait loop with a
0438 D0 F9 BNE $0433 ; harmless side effect.
043A BD E0 04 LDA $04E0,X ; Map from logical sector in X to physical sector in A
043D 8D 22 03 STA $0322 ; Store desired sector to the sector register
0440 A0 00 LDY #$00 ; Set output pointer to 0
0442 A9 80 LDA #$80
0444 8D 20 03 STA $0320 ; Initiate command $80 (i.e. read sector)
0447 2C 12 03 BIT $0312 ; Check status.
044A 70 12 BVS $045E ; If read sector is finished, exit loop to $045e.
044C 10 F9 BPL $0447 ; If no new byte is ready yet, loop back to checking status.
044E AD 23 03 LDA $0323 ; Read new data byte.
0451 91 60 STA ($60),Y ; Store byte.
0453 C8 INY
0454 D0 F1 BNE $0447
0456 E6 61 INC $61
0458 4C 47 04 JMP $0447 ; Increment output pointer; increment Y first, increment $61 if there's carry.
045B 4C 00 04 JMP $0400
045E AD 20 03 LDA $0320 ; Enter here upon completion of a read sector.
0461 29 9C AND #$9C
0463 D0 F6 BNE $045B ; If the post-read-sector status indicates any of: drive not ready, CRC error,
; sector not found, data not completely read, retry the whole process from step 1.
0465 E8 INX
0466 68 PLA
0467 48 PHA ; Increment X, get A back from the top of the stack (and leave it there).
; This appears to be a current sector count.
0468 C9 07 CMP #$07
046A D0 04 BNE $0470
046C E0 0A CPX #$0A
046E B0 04 BCS $0474 ; If that was sector 7 of track 10, stop.
0470 E0 0B CPX #$0B
0472 90 C6 BCC $043A
0474 68 PLA
0475 F0 A2 BEQ $0419 ; This is impossible in the code as given, so presumably modification occurs?
0477 C9 01 CMP #$01
0479 F0 9B BEQ $0416 ; As above.
047B 78 SEI
047C D8 CLD
047D A2 FF LDX #$FF
047F 9A TXS
0480 AD 80 03 LDA $0380
0483 A0 00 LDY #$00
0485 98 TYA
0486 99 00 00 STA $0000,Y
0489 99 00 02 STA $0200,Y
048C 99 37 98 STA $9837,Y
048F C8 INY
0490 D0 F4 BNE $0486 ; Zero out the zero page, page 2 and the 256 bytes from $9837
0492 20 1C 95 JSR $951C
0495 A9 0C LDA #$0C
0497 20 D4 96 JSR $96D4
049A 20 2E 6C JSR $6C2E
049D 20 44 6F JSR $6F44
04A0 B0 B9 BCS $045B
04A2 20 0A 96 JSR $960A
04A5 AD 01 C0 LDA $C001
04A8 C9 59 CMP #$59
04AA F0 16 BEQ $04C2
04AC 20 B2 68 JSR $68B2
04AF A9 03 LDA #$03
04B1 20 B8 73 JSR $73B8
04B4 90 0A BCC $04C0
04B6 A9 EB LDA #$EB
04B8 A0 04 LDY #$04
04BA 20 0C 73 JSR $730C
04BD 4C 7B 04 JMP $047B
04C0 A9 00 LDA #$00
04C2 8D FD 97 STA $97FD
04C5 A2 02 LDX #$02
04C7 BD DD 04 LDA $04DD,X
04CA 9D 05 E9 STA $E905,X
04CD A9 3F LDA #$3F
04CF 9D E0 02 STA $02E0,X
04D2 CA DEX
04D3 10 F2 BPL $04C7
04D5 A9 60 LDA #$60
04D7 8D 09 F4 STA $F409
04DA 4C 00 C0 JMP $C000
04DD 4C 00 68 JMP $6800
04E0
; Logical to physical sector mapping table:
db $01, $03, $05, $07, $09, $0b, $02, $04, $06, $08, $0a
; Text:
ds "\a*ERR-NO COM.*?\r\n\0"
04FD D4 ???
04FE C5 C5 CMP $C5
0500 .END
Re: Is BD-DOS lost to time?
Here the $2C opcode (i.e. BIT instruction) is used to mask following 2 bytes.ThomH wrote: ↑Tue Jan 28, 2020 1:08 amCode: Select all
* = 0400 .................................... 0415 2C A9 00 BIT $00A9 ; Unknown purpose. 0418 2C A9 07 BIT $07A9 ; Unknown purpose. .................................... 0475 F0 A2 BEQ $0419 ; This is impossible in the code as given, so presumably modification occurs? 0477 C9 01 CMP #$01 0479 F0 9B BEQ $0416 ; As above. ....................................
Then the jumps at $0475 and $0479 make perfect sense .
Code: Select all
* = 0400
....................................
0415 2C NOP ; BIT opcode is used to mask next LDA imm. instruction
0416 A9 00 LDA #$00
0418 2C NOP ; BIT opcode is used to mask next LDA imm. instruction
0419 A9 07 LDA #$07
....................................
0475 F0 A2 BEQ $0419 ; Jump to load A with #$07
0477 C9 01 CMP #$01
0479 F0 9B BEQ $0416 ; Jump to load A with #$00
....................................
- can load sectors with bigger size than 256 bytes;
- uses sector interleave (i.e. logical to physical mapping) - it's interesting how effective it's actually? Recently I've played bit with the Jasmin loader code to use interleave, but because of many conversions DSK->HFE->FlashFloppy internal data interpretation it's not clear if the interleave in the DSK still "de facto" preserved.
BTW, your post is just in time (again) for me - I'm wondering if I can support booting with Byte Drive 500 hardware together with Jasmin/Microdisc/8D-FDC .
- mikeb
- Flight Lieutenant
- Posts: 282
- Joined: Wed Sep 05, 2018 8:03 pm
- Location: West Midlands, UK
- Contact:
Re: Is BD-DOS lost to time?
Code: Select all
0400 2C 11 03 BIT $0311 ; Unknown purpose.
0403 2C 17 03 BIT $0317 ; Unknown purpose.
The above two however I would say are NOT used to "hide" instructions in the same way. Note the addresses. These are effectively reads from I/O locations, $0300-$030F is the onboard 6522 VIA, $0310+ would be registers/flipflops on the disc interface. Someone with more experience of the specifics of the disk hardware could chip in here to confirm, but I believe this is resetting/setting some hardware in the disc interface ...
On a Cumana interface, $0311 is the track register of the FDC chip (is this a quick way to select track 0?) and $0317 doesn't seem to be decoded.
Re: Is BD-DOS lost to time?
From testing different combinations, I'm actually pretty sure that one of those BITs is responsible for disabling the BASIC ROM. I don't know what the other does, and I don't know which is which.
I considered that maybe the side select is undefined at startup on the BD-500, the intention being just to put the same boot sector on both sides and deal with it in software, but since it shipped with a single-sided drive and correspondingly we have only a single-sided disk image for testing, that's massive speculation.
There are some other mystery accesses in the DOS itself, but I haven't yet disassembled that. I've just been watching the address accesses. I could also venture a pretty random guess that some of them might be drive selection, but that's also plucked out of thin air.
Pretty much all that does seem certain is that motor control is automatic (or else it'd never boot), so none of the mystery accesses are likely to be related to that, and the FDC is the standard WD type so ditto stuff like stepping is automated. I guess there might also be an exposed FM/MFM selector.
I considered that maybe the side select is undefined at startup on the BD-500, the intention being just to put the same boot sector on both sides and deal with it in software, but since it shipped with a single-sided drive and correspondingly we have only a single-sided disk image for testing, that's massive speculation.
There are some other mystery accesses in the DOS itself, but I haven't yet disassembled that. I've just been watching the address accesses. I could also venture a pretty random guess that some of them might be drive selection, but that's also plucked out of thin air.
Pretty much all that does seem certain is that motor control is automatic (or else it'd never boot), so none of the mystery accesses are likely to be related to that, and the FDC is the standard WD type so ditto stuff like stepping is automated. I guess there might also be an exposed FM/MFM selector.
- ibisum
- Wing Commander
- Posts: 1655
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Re: Is BD-DOS lost to time?
Is the other BIT maybe for ROM bank select?
Re: Is BD-DOS lost to time?
I currently suspect $310 and $313 as enable and disable overlay RAM respectively, and $317 as disable BASIC ROM. Though that definitely could be $311.
That being said, I notice that the code at 04A5 is likely a test for BASIC 1.0, so very possibly I'm wrong about the function of _both_ $311 and $317.
To quote someone smarter, if online translation is reliable, then Fabrice's thoughts were:
That being said, I notice that the code at 04A5 is likely a test for BASIC 1.0, so very possibly I'm wrong about the function of _both_ $311 and $317.
To quote someone smarter, if online translation is reliable, then Fabrice's thoughts were:
$0310: switch on the RAM overlay?
$0311: ?
$0312: DRQ/IRQ status register
$0313: switches on the ROM?
$0314: switches on the RAM overlay? But can leave the EPROM visible?
$0315: ?
$0316: deselection of the lower 8kb of the EPROM overlap to allow access to the RAM overlay?
$0317: EPROM access? If the EPROM is 8kb, 8kb of overlay RAM is visible too?
Or does $0317 plus $0314 give access to the EPROM in reading and the RAM in writing?
- mikeb
- Flight Lieutenant
- Posts: 282
- Joined: Wed Sep 05, 2018 8:03 pm
- Location: West Midlands, UK
- Contact:
Re: Is BD-DOS lost to time?
$0310-$03FF is definitely going to be I/O to the disk hardware. Beyond that, ?
If someone has a proper schematic of this board, then what the addresses do can be derived from the schematic, otherwise it's either guesswork or relying on someone having documented source code
At least some copies of the Cumana disk interface circuit have hand added annotations of what different lines enable, based on decoding out the address bus (and then further, by chasing into the documented registers of the FDC chip, and an 8-bit latch used for miscellaneous on-board stuff, e.g. side 1/2, drive 0-1-2-3 select, Ext boot rom or not etc. but they don't seem to align with this, as $317 isn't anything at all on there.
Need schematics ...