forum.defence-force.org

Posted: **Tue Jan 14, 2020 4:11 pm**

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?

Posted: **Tue Jan 14, 2020 5:48 pm**

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/

Posted: **Tue Jan 14, 2020 9:18 pm**

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.

Posted: **Tue Jan 14, 2020 9:19 pm**

: euphoric-bddos.png (39.09 KiB) Viewed 13185 times

(All thanks go to Fabrice Frances (aka Euphoric him self

).
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

This is everything that I know and have related to BD500/BDDOS.
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

.

Posted: **Tue Jan 14, 2020 11:36 pm**

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:

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.

Vectors are NMI -> $022b, reset -> 0xe000, IRQ -> 0228, for the record. So guesses:

* 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).

EDIT: inspecting what we can therefore conclude is the boot sector reveals a weird result: it's a 512-byte sector. Which means that the ROM loop above will overwrite the first half with the second half. But also the sector itself just contains the same 256-byte sequence repeated twice. Disassembling that:

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

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:

a WD1973;
with motors tied to a head load request, but head loaded signalled only when a drive is signalling ready.

... and that gets me beyond the boot sector, and a few sectors further, to needing to figure out the expectations around the non-WD registers. I have Fabrice's notes, so will proceed with those.

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).

Posted: **Thu Jan 16, 2020 2:37 am**

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':

: Clock Signal Screen Shot 15-01-2020, 20.30.44 GMT-5.png (8.51 KiB) Viewed 13134 times

Posted: **Thu Jan 16, 2020 4:59 am**

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.

Posted: **Fri Jan 17, 2020 4:01 am**

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.

Posted: **Tue Jan 28, 2020 1:08 am**

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

Posted: **Tue Jan 28, 2020 1:52 am**

ThomH wrote: ↑Tue Jan 28, 2020 1:08 am

Code: 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.
....................................

Here the $2C opcode (i.e. BIT instruction) is used to mask following 2 bytes.
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
....................................

Cool code and remarkable are 2 things:
- 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

.

Posted: **Tue Jan 28, 2020 9:34 pm**

Code: Select all

0400   2C 11 03   BIT $0311	; Unknown purpose.
0403   2C 17 03   BIT $0317	; Unknown purpose.

The comment from @iss relating to the other BIT instructions is a good observation, and it's always interesting when tricks like that slide into assembler

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.

Posted: **Wed Jan 29, 2020 4:01 pm**

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.

Posted: **Wed Jan 29, 2020 6:59 pm**

Is the other BIT maybe for ROM bank select?

Posted: **Wed Jan 29, 2020 7:55 pm**

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:

$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?

Posted: **Thu Jan 30, 2020 5:43 pm**

ThomH wrote: ↑Wed Jan 29, 2020 7:55 pmpossibly I'm wrong about the function of _both_ $311 and $317.

$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 ...

Posted: **Fri Jan 31, 2020 10:32 pm**

Alas the Byte Drive 500 seeks to put all the machine-specific logic "into the cable". So the main controller box and the drive are machine independent, and if you change your machine, you just buy the new cable. I don't know exactly what these cables looked like, other than that they must be quite ungainly, but I guess it's likely that they give much lower internal accessibility than an ordinary interface. Therefore even if these weren't extraordinarily rate, it's more than usually unlikely that anybody has drawn up a schematic.

I might keep an eye on eBay, but I'm not going to hold my breath.

Posted: **Sat Feb 01, 2020 4:17 am**

Here is how the "Hybrid" cable looks:

: bd500.png (582.82 KiB) Viewed 12177 times

Found in "Computer Answers" 1984/05 pages 19&20. Recently I found somewhere better picture but unfortunately I forgot to save it and now I can't track it again. But anyway I doubt that there is a hope to have the schematics

. Even if we have the hardware the hybrid chips will be "sealed" like that:

: hybrid.jpg (34.12 KiB) Viewed 12177 times

Posted: **Sat Feb 01, 2020 4:33 am**

... but we move slowly further:

: side-by-side.png (65.34 KiB) Viewed 12176 times

Clksignal and Oricutron side by side running BD-DOS! Do you notice the difference

Yes, Oricutron supports more drives!

The secret is: write to address $31A - drive select as follow:

Code: Select all

  switch( addr )
  {
    case 0x31a:
      switch( data & 0b11100000 )
      {
        case 0b00100000:
          bd->wd->c_drive = 0;
          break;
        case 0b01000000:
          bd->wd->c_drive = 1;
          break;
        case 0b10000000:
          bd->wd->c_drive = 2;
          break;
        case 0b11000000:
          bd->wd->c_drive = 3;
          break;
      }
      break;
  }

EDIT: To check drives use: "DIR,D0", "DIR,D1", "DIR,D2" and "DIR,D3". The last used drive remains as "current drive" for next command.

I'm preparing new Oricutron developer release with BD-500 support and some goodies (and with special thanks to @ThomH), just waiting the date 2020-0202 - simply it looks cool for release name

Posted: **Sat Feb 01, 2020 8:41 pm**

iss wrote: ↑Sat Feb 01, 2020 4:17 am Here is how the "Hybrid" cable looks:

Well thanks for digging that up -- and "Yuck!"

"revolutionary advance in the world of home computing" -- more like annoying retrograde step to prevent it ever being understood!

Looks like both sides have COB (chip on board) under epoxy blobs, like used on digital watches, music greeting cards etc. How annoying -- so it's likely there's no meaningful schematic if they've done that AND used some proprietary logic bits too.

Posted: **Mon Feb 03, 2020 5:18 pm**

The list of things that Oricutron does but Clock Signal does not is usually too intractable to be worth commenting on, but thats great new information and Clock Signal will endeavour to catch up in the near future! Probably before the next palindromic date, but we'll see.

It actually could be interesting to see a schematic of just the non-cable bit of a Byte Drive 500 to find out what's meant to be selectable from the machine — e.g. is there a side toggle? Is there a double-density toggle? — but I doubt we'll even see that since the hardware itself is so obscure. I'm not sure even a scan of whatever documentation came with the drive survives?

Posted: **Mon Feb 03, 2020 6:23 pm**

ThomH wrote: ↑Mon Feb 03, 2020 5:18 pm non-cable bit of a Byte Drive 500 to find out what's meant to be selectable from the machine — e.g. is there a side toggle? Is there a double-density toggle?

From the article above, it seems the COB interface board for Oric is just there to provide an Oric (Atmos) specific boot ROM/hardware logic/WDC compatible floppy chip because Oric, out of the box, is missing all these things.

It states it has a 34-way connector to the drive, and implies that computers with a proper disk interface don't need this board.

So I would assume that the 34-way cable is a standard Shugart floppy interface. Therefore, the signals on it would be as per

https://en.wikipedia.org/wiki/Floppy-disk_controller

Scroll down to the "Interface" bit, and ignore the PC-specific stuff about twisting the cable

Posted: **Mon Feb 03, 2020 7:37 pm**

Oh, I had missed that the disk controller is in the cable; I'd assumed that the WD-or-equivalent was either in the box that is primarily a PSU, or in the drive itself*, with the cable just being the machine-specific ROM and whatever is necessary to do that machine's address decoding as input to the drive controller**.

So, yeah, you're right — there'll probably never be a schematic, of anything.

* not so crazy, e.g. the SAM Coupé does this, giving you one controller per drive.

** since I'm not even completely confident of the difference between a latch and a flip flop, I'm being deliberately vague here. But I guess, if the other electronics were on the far side of the cable then it'd just be generating appropriate chip selects. Assuming it's still called a chip select if it only goes to a flip flop. Or a latch.

Posted: **Mon Feb 03, 2020 7:53 pm**

mikeb wrote: ↑Mon Feb 03, 2020 6:23 pmSo I would assume that the 34-way cable is a standard Shugart floppy interface.

+1!

ThomH wrote: ↑Mon Feb 03, 2020 5:18 pmThe list of things...

It was not meant to be offensive in anyway! With full respect I'm sorry for the unsuccessful joke. Actually I was very excited to share the "discovery" about $31A.

ThomH wrote: ↑Mon Feb 03, 2020 5:18 pmIs there a side toggle? Is there a double-density toggle?

I vote for these too - there are "pings" to $314 and $316 on every command being executed and I can't think-off anything else more clever.

And this is the only piece of info which I found today:

: Oric-1-48K-version-DOS-Users-Manual.jpg (19.74 KiB) Viewed 12113 times

Just the cover and returned by g**gle as match on image search with keywords: "spectrum" "byte drive 500"

Posted: **Mon Feb 03, 2020 8:26 pm**

... and this in "TILT" magazine misspelled as "Bute Drive 500":

: bUte-drive.png (797.81 KiB) Viewed 12111 times

Automatic translate:

DRIVE: The long awaited floppy drive for Oric 1 and Atmos is finally available in France from JGS. This is I.T.L.'s Bute Drive 500 Kathmill which gives 440 K-bytes after formatting, or 220 KB per side on three inch floppy disks. The DOS, very complete, is supplied in ROM; it allows direct access or sequential access to data files. This Drive provides ten additional basic instructions to Oric computers, such as "On Error". The BD 500 is announced as compatible with the Spectrum, the Commodore 64, Y Electron ..., just change the interface cable. This floppy disk drive is offered at around 3980F by JCS.

Not very useful, but confirms the 2 sides floppy disks!

Oh, and the command format almost works:

Code: Select all

FORMAT"SOMETHING",D1

The command finishes with error and it still not clear what "something" is - I think it can be like disk name or (which I prefer) the name of the "autoexec" program i.e. in the bddos.dsk is a program named "HELLO" and it's started just after boot.

Posted: **Mon Feb 03, 2020 10:44 pm**

For those interested, I found back a CEO-Mag index done by André C.
There it goes concerning Byte Drive:

BYTE DRIVE 500 ET BD-DOS

Article / Mag issue
BDdos et Euphoric / 204,
Brève : BD-500 drive / 153,
Brève : The BD 500 drive / 145,
Courrier / 246,
ITL Kathmill / 128,
Le lecteur BD 500 / 145,
Le DOS du lecteur BD 500 / 151,
Nostalgie... / 162,
Old2mfm, Mfm2raw & Raw2fm / 154,
Premières informations sur BD-DOS / 154, 155,
Résurrection d'un DOS / 153,
Vitesslec / 154

Posted: **Wed Feb 05, 2020 12:16 am**

Symoon wrote: ↑Mon Feb 03, 2020 10:44 pmFor those interested ...

Thanks for the info, @Symoon!

Well, I spend looot of time on this but IMO it's worth!

Attached you can find every single bit of info related to Byte Drive 500 which can be found in the internet archive and with little hacking the images are in the highest resolution!

In the Zip file you will find short summary of the BD-DOS commands. The guess in my previous post about the command parameter FORMAT"SOMETHING" is now proven - "SOMETHING" is the name of the auto-start program after boot!

Additionally it is confirmed that "everything is in the cable" i.e. the floppy drive is just ... a floppy drive. (more info for BD-500 and SAM Coupé scroll page down).

And here is my precious "die shot" like picture of the hybrid controller board:

: die-shot.jpg (233.22 KiB) Viewed 12074 times

Unfortunately, the title of the last article in the ZIP file tells the whole story:

: end-of-story.png (13.9 KiB) Viewed 12074 times

Posted: **Wed Feb 05, 2020 1:21 pm**

thanks for the effort!
I'm not going to help much on that topic, but I saved the file anyway

Posted: **Tue Mar 03, 2020 11:52 pm**

I have a ByteDrive. Actually a pair with documentation.

I did bid on that manual shown above but got outbid.
I have a lot of information to go through but havent' had the time to even unpack the ByteDrives.
I might just sell them on as I'm not getting the opportunity to look at it properly and don't have space for it.

I'm really not sure, but I'm going to scan the documents when I get chance, before doing anything else.

The ByteDrive software was written by Peter Halford. There was a Byte Drive User group but it only had 30 or so members. Dr Ray Mclaughlin updated the software and write programs for the Bytedrive including his WordSpeed word processor which he rewrote for Sedoric. There's some other updated programs including Composer. I haven't been able to look at any of this stuff yet to see what differences there are or if/ how it can be transferred to Sedoric.

The System seems to come with a BASIC V3 Rom. I'm not sure if this can be used without the BD system. There's a separate card to take the ROM. I think there was a V4 version on that board. As I say - I haven't had chance to look properly at it .

So for BDDOS there was the original Halford and then at least 3 revisions. I should have at least a couple of these.

Posted: **Wed Mar 04, 2020 1:56 am**

Steve M wrote: ↑Tue Mar 03, 2020 11:52 pmI have a ByteDrive.

Wow! This is amazing.
All paper scans will be great and helpful.
@Steve M: If you decide to sell any ByteDrive stuff count me as a candidate!

Else I'm ready also to borrow it for some short time and cover all two-way postage.

Posted: **Wed Mar 04, 2020 5:34 pm**

iss wrote: ↑Wed Mar 04, 2020 1:56 am
Steve M wrote: ↑Tue Mar 03, 2020 11:52 pmI have a ByteDrive.
Wow! This is amazing.
All paper scans will be great and helpful.
@Steve M: If you decide to sell any ByteDrive stuff count me as a candidate!
Else I'm ready also to borrow it for some short time and cover all two-way postage.

Whatever happens to the drive, would be cool if somebody could make a video showing the system, how it looks like, how it works, etc... how it compares with the microdisc or jasmin (speed, reliability, ...) , etc...

Posted: **Wed Mar 04, 2020 7:41 pm**

I'm the last person who should end up in physical possession of it, ever, but I can definitely chip in towards purchasing it with/for @iss, if it's for sale. I suspect we won't get a second chance.

Posted: **Thu Mar 05, 2020 10:06 pm**

I guess it will be at some point but I'll have to get the paperwork scanned.

Posted: **Sat May 16, 2020 11:12 pm**

One more step further with last Oricutron support of Byte Drive 500.

BD-500 emulation works with Oric-1 ROM 1.0 and with the Atmos ROM 1.1b.

THIS is the current portion of code handling the I/O read operations from BD-500 hardware. Most interesting is how read from address 0x317 affects the memory size being recognized by the HELLO program:

Code: Select all

    case 0x317:
      // 64k/56k mode depend on ROM chips
      bd->diskrom = bd->oric->rom16? SDL_FALSE : SDL_TRUE;
      break;

The whole thing is based only on "astrology" by now

. I've implemented a parameter in Oricutron.cfg file:

Code: Select all

; Specifies how ROMDIS disables ROM chip(s)
; related to BD500/BDDOS
; rom16 = yes - 64k mode (Default)
; rom16 = no  - 56k mode
;rom16 = yes

The purpose is to control if reading from 0x317 turns off the external ROM.
This is the result when the parameter is changed:

: 64k-56k.png (40.72 KiB) Viewed 11331 times

Here is the Basic source of the HELLO program:

Code: Select all

10  '--- GREETING PROGRAM ---'   
20 ON ERROR GOTO 300
30  TEXT:WINDOW:CLS:NORMAL   
40  CR$=CHR$(13):QT$=CHR$(34):AD=#97FE
100 DEFKEY$(0) = CHR$(96) '` SYMBOL .
110 DEFKEY$(1) = "LIST"+CR$    
120 DEFKEY$(2) = "RUN"+CR$ 'RUN AUTO .
130 DEFKEY$(3) = "RUN"+QT$ 'RUN "" . 
140 DEFKEY$(4) = "DIR"+CR$ 'DIR AUTO .
150 DEFKEY$(5) = "HIYA KOFFERS!" 
160 DEFKEY$(6) = "LOAD"+QT$ 'LOAD"" .
170 DEFKEY$(7) = "HIRES"+CR$ 'HIRES .
180 DEFKEY$(8) = "COLOR 4,7"+CR$'TRYIT
190 DEFKEY$(9) = "TE.:MR."+QT$+"WORDPROCESSOR"+CR$  
200 'NOW DISPLAY CREDITS AND DATE .
220 DEF FN A(Q) = (40-LEN(A$))/2
230 A$="DOS DISK CREATED FEB 20 1984"
240 PRINTTAB(FNA(1));A$
250 IF SYS(20) THEN A$="64k" ELSE A$="56k"
260 IF PEEK(AD-1)=0 THEN A$=A$+" ATMOS" ELSE A$=A$+" ORIC1"
265 HTAB 0,2:PRINTTAB(FNA(Q));A$
270 A$="VERSION "+STR$(PEEK(AD))+"."+RIGHT$(STR$(PEEK(AD+1)),LEN(STR$(PEEK(AD+1)))-1)        
280 HTAB 0,4:PRINTTAB(FNA(Q));A$   
290 CAPS:VTAB 20:END
300 IF ERR(0) = 14 THEN RESET '^C !
310 STOP

Line 250 handles ONLY two possibilities 64k or 56k - and this really puzzles me!
If it was 64k vs. 48k - it's clear and OK, but how is possible to have 56k and not the whole 64k? What do you think?

Posted: **Sun May 17, 2020 12:57 am**

Could the controller be putting his own 8k ROM in the overlay area, leaving other 8k of ram for the user?

Posted: **Fri May 22, 2020 9:44 pm**

I'm not sure which version of BD DOS it is? I have documentation for DOS4 which includes BASIC v2. So I'd assume there has to be some overlay with the new Basic. I have an Oric with an expansion pack that houses a ROM chip with the Basic - I think that one is V3 BASIC.

After the initial software by Peter Halford, Dr Ray McLaughlin rewrote the DOS and Basic and there are several updates. Some of the updates didn't seem to work properly judging by the corrospondance I have, which led to further amendments.

Let me know if you want Basic V2 DOS 4 manual

Posted: **Sat May 23, 2020 7:36 am**

Steve M wrote: ↑Fri May 22, 2020 9:44 pmI'm not sure which version of BD DOS it is?
... Let me know if you want Basic V2 DOS 4 manual

The HELLO program reports version 2.2. Any information is wanted and highly appreciated, please!
Manuals and even some pictures of the hardware are real treasure

.

Posted: **Tue May 26, 2020 9:18 pm**

Some additional info about the released BD-DOS versions and their full naming:

BD DOS 2.2 with BASIC ROM 1.0 - this is what we have so far.
BD DOS 3.1b with BASIC ROM ?.?
BD DOS 3.2 with BASIC ROM ?.?
BD DOS 4.0 with BASIC ROM 2.0

With every next version some bugs were fixed and commands added.
Interesting is the BASIC ROM x.x part - for the tested version 'with BASIC ROM 1.0' means exactly ORIC BASIC 1.0

.
After boot DOS loads itself in area #6800..#9800 and loads a copy of BASIC 1.0 (i.e. the Oric-1 one) in the whole RAM Overlay.
This copy differs from the original ROM in only 12 bytes - used to redirect keyboard and print to screen routines to the DOS code (I guess). It's little strange because you have to use the buggy ROM 1.0 even if you have an Atmos, but this is obviously changed and the later versions (i.e. DOS 4.0 with BASIC ROM 2.0) are Atmos BASIC 1.1b based, I think.

Posted: **Wed Jun 17, 2020 5:29 pm**

From Personal Computer News (PCN) March 10 1984 :-

A review of the ITL Kathmill "hybrid" cable, describing it as a chips-on-ceramic-baked-in-resin (YUM!) device, and also mentioning it has its own ULA on board which implements the disk controller (so not a standard WD part, but a compatible emulation?)

Thought I'd better clip it and post it here for posterity.

Posted: **Sun Jun 28, 2020 6:38 pm**

Thanks Mike. I think those pages are in the collection Iss posted earlier.
The picture shows a 'naked' hybrid as the real ones have a 'blister' over the ICs. (I'm not sure if that is just protective or has some other use?)
Normally the plastic case is sealed shut. It's really an interface that is as wide as the cable. It's using miniature components which seems ahead of it's time. I guess if they used conventional components it would have been the size of a Cumana board.

As the components are so small it's a bit hard to tell how much they used custom-made components. They seemed to have a lot of difficulty with the 'hybrid' though.

I wonder if you'd be able to read a 3" disk? maybe do a disassembly? I could post something like that if you'd like to have a look.
I have yet to test whether the BD disks could work on other systems.

Posted: **Sun Jun 28, 2020 8:20 pm**

@SteveM: Thanks for all your BD-500 scanned docs. I converted them to PDFs and they should appear soon in DF library.

For all impatient Oric-hackers here are temporary links:

BD-500-DOS-4.0-BASIC-2.0-Users_Manual.pdf ~ 56MB
BD-500-DOS-4.0-BASIC-2.0-Specs.pdf ~ 1.8MB
BD-500-DOS-4.0-BASIC-2.0-TypeMe.pdf ~ 2.4MB

Steve M wrote: ↑Sun Jun 28, 2020 6:38 pmI wonder if you'd be able to read a 3" disk?

The first option is to connect the 3" drive to an old PC and create image.
Else it's possible to read the 3" BD-500 disks with (for instance) Microdisc interface and 3" floppy drive. The only problem is that BD-500/BD-DOS uses sectors with 512 bytes each, so we need a new copy program ... which can be done soon

.

Posted: **Sun Jun 28, 2020 8:58 pm**

Steve M wrote: ↑Sun Jun 28, 2020 6:38 pm the real ones have a 'blister' over the ICs. (I'm not sure if that is just protective or has some other use?)

I wonder if you'd be able to read a 3" disk? maybe do a disassembly? I could post something like that if you'd like to have a look.
I have yet to test whether the BD disks could work on other systems.

The "blister" is usually a blob of hard, opaque, epoxy (to protect any gold "bond wires" between the edge of the silicon and the board) -- it also prevents people staring at the chip and reverse engineering it (allegedly

... and also importantly it keeps light off the chips, as all those silicon P/N junctions can be sensitive to light, and therefore misbehave when illuminated.

Case in point: Anyone that used a flash to photograph early versions of the Raspberry PI 2B ... (instant crash due to one bare-silicon device!)

I can't see any bond wires in the published "naked" pictures, so it could be this is one where they've mounted the parts on the ceramic backing, but not yet wired them across from the dies to the gold tracks, and then later blobbed the ICs and dipped the whole thing to protect it all.

Not sure if the second point was directed to me, but just in case, I can't read 3" disks (no drives/disks)

Posted: **Mon Jun 29, 2020 12:13 pm**

OK, Mike.

Yes, my old PC with the floppy controller is not booting, so I can't convert things.
I've got some more memory but I think the BIOS settings arent' right. I need to have another look at it.

Posted: **Tue Jun 30, 2020 4:23 pm**

iss wrote: ↑Tue May 26, 2020 9:18 pm Some additional info about the released BD-DOS versions and their full naming:

BD DOS 2.2 with BASIC ROM 1.0 - this is what we have so far.
BD DOS 3.1b with BASIC ROM ?.?
BD DOS 3.2 with BASIC ROM ?.?
BD DOS 4.0 with BASIC ROM 2.0

Looking at my disks I can expand this a little There is also
BD DOS 5.0 with BASIC v3.0
BD DOS 5.0 version 2(?)
BD DOS 5.0 with BASIC v3.1
BD DOS 6.0 with BASIC v4.0

(and I now have a DOS6.0 manual to scan !!!)

Posted: **Tue Jun 30, 2020 4:40 pm**

Some pics/

Posted: **Tue Jun 30, 2020 6:37 pm**

Steve M wrote: ↑Tue Jun 30, 2020 4:23 pm Looking at my disks I can expand this a little There is also
BD DOS 5.0 with BASIC v3.0
BD DOS 5.0 version 2(?)
BD DOS 5.0 with BASIC v3.1
BD DOS 6.0 with BASIC v4.0
(and I now have a DOS6.0 manual to scan !!!)

Wooow, this is incredible!

I can wait to have copy of all that stuff!

@SteveM: Do you have working Oric setup with Microdisc controller, 3" floppy drive (for reading of BD-DOS disks) and Gotek as second floppy drive (to store the dumped image and easy transfer to PC world) ?
I'm ready to create very quickly a copy program which will do the above job dealing with BD-DOS specific format!

Posted: **Tue Jun 30, 2020 10:39 pm**

I've got BD drives and Microdisc drives. I've got Cumana with 3.5" drives. I don't have a Gotek yet.
I've been holding off from getting a Gotek as there is the issue with files being converted to it's format. I'm not aware of anything that can get the files back to Oric .dsk files (?)

My Opel interface had the 3" and 3.5" drives. It's gone wrong so need repairing.

I used to copy thing on there from the 3" to 3.5" then I'd use the Cumana with 2 3.5" drives. I used to copy 3.5" floppies on the PC. Now my old PC need repairing

Can you connect a real drive to the Cumulus? I thought that might be a way to convert files.

I haven't booted up the BD system yet. I don't have much room. As it is the Atmos is sitting on top of the Atari ST which share an (Einstein) monitor.
I've been scanning the paperwork first to try and preserve something of the system.

Posted: **Wed Jul 01, 2020 12:23 pm**

Steve M wrote: ↑Tue Jun 30, 2020 10:39 pm I've got BD drives and Microdisc drives. I've got Cumana with 3.5" drives. I don't have a Gotek yet.
I've been holding off from getting a Gotek as there is the issue with files being converted to it's format. I'm not aware of anything that can get the files back to Oric .dsk files (?)

Yep. That is indeed an issue. I think I once suggested Oricutron supporting edsk (Amstrad CPC) disk format. It is a container, similar to our dsk, which is natively supported by the Gotek's firmware. The software tool can convert from dsk to edsk (but not the other way round) too, and it is also supported in the MiSTer, SiDi, etc. Oric cores. Having it supported in Oricutron would ease things a lot, but also a conversion tool could be created.

My Opel interface had the 3" and 3.5" drives. It's gone wrong so need repairing. I used to copy thing on there from the 3" to 3.5" then I'd use the Cumana with 2 3.5" drives. I used to copy 3.5" floppies on the PC. Now my old PC need repairing

Can you connect a real drive to the Cumulus? I thought that might be a way to convert files.

I also have an old laptop to be able to write 3.5 disks with WRITEDSK, but eventually it will fail and I will get stuck with no way to produce physical floppies. It should be possible to plug a real floppy and a gotex in my Microdisc clone and create physical disks from disk images, but only if they are DOS-friendly (Sedoric, OricDOS,...). We don't have (yet) a tool to duplicate disks at low level (no dos, different, or variable, geometry, etc.). And, as you said, the other way round is not possible. You end up with an hxc floppy image you cannot convert to Oric dsk (see above, my discussion about edsk format).

About using a PC, the only solution I've seen so far is Greaseweazle. Not easy if you are not good with the soldering iron (I suck!).

And the answer to your question is no. The Cumulus emulates the Microdisc controller and the 4 floppy drives. There is no way to connect a real one.

Posted: **Wed Jul 01, 2020 4:29 pm**

Chema wrote: ↑Wed Jul 01, 2020 12:23 pm And the answer to your question is no. The Cumulus emulates the Microdisc controller and the 4 floppy drives. There is no way to connect a real one.

That's a shame. I thought the jumper on the board was to switch between drives? Anyway, it's a missed opportunity. I guess that leaves the Cumana reborn as the better alternative - but still the issue of transferring files.

I better get back to fiddling with my old PC.

The Greasweazle looks interesting. Apparently you can get them soldered or fully assembled. I can';t see where to get any of the hardware though.

Anyway, here's some more pics.

Posted: **Wed Jul 01, 2020 5:42 pm**

More exactly, Cumulus is a software emulation, since it was only designed to talk to a SD Card, there's no attempt at handling things like the time it takes to spin a motor, change track, etc... that's why it's super compact. Cumana Reborn is a real Cumana disk controller which just happen to be modified to have a gotek on board.

Posted: **Wed Jul 01, 2020 6:16 pm**

Chema wrote: ↑Wed Jul 01, 2020 12:23 pm About using a PC, the only solution I've seen so far is Greaseweazle.

@Chema: Thanks for the link. I didn't know about this nice project - it looks great. I've created something similar based on Arduino but it's in early stage, so Greaseweazle will save my time for something else

.

Cumana reborn can be a solution - IIRC it's normal Cumana controller integrated with Gotek and allows to connect additional floppy drive.
@SteveM: Do you have Cumana reborn? If so, can you try to test how it's functioning with additional 3" floppy? And If everything seams to work I'll create a copy program which will dump the BD-DOS disk from the real 3" drive to an USB HFE-image and a PC tool which will convert HFE to normal DSK image.

Posted: **Fri Jul 03, 2020 6:50 pm**

I've not got a Cumana Reborn yet as I've got Cumana boards. I was hoping Piotr (is that the right name?) would want to build them, but he wanted to make them smaller and came up with the Reborn design. I've got 2 or 3 that I've half-made. More projects to do !!!
I know the Cumana interface will accept any of the drives - 3", 3.5" or 5.25" - it's a matter of setting up the drive configuration on Sedoric. I'm not sure how that would work with other DOS systems(?) I assume there's some similar part of the DOS that tells the system the right partitions/ sectors etc. I don't know if the HFE works with 3" configuration?

I've got all the old gear(OPEL interface, Cumana interface, Miscrodisc interface, 3" drives, 3.5" drives, 5.25" drives), some of the new stuff (Cumulus, Erebus) but not something to transfer things, at the moment. I might be able to get my hands on another PC soon which would make things easier.

I think I need to sell some Oric gear so I can afford to buy some Oric gear!!!

Posted: **Fri Jul 03, 2020 8:18 pm**

Unfortunately, this Cumanas will not do the job - it's the same as Microdisc and any other FDC i.e. you still need a Gotek to transfer files between Oric and PC. (Actually maybe I mislead you saying "Cumana reborn" I meant the one with integrated Gotek).

I think in this case the best will be PC with attached floppy (3" or 3.5" depending on the BD-DOS disks) and OmniFlop which work just fine for analyzing and reading strange floppy formats.

Posted: **Fri Jul 03, 2020 8:18 pm**

I have a Microdisc clone with two 3.5 drives. Sedoric works with no need of any configuration. I've also seen it work with one 3.5 and one 5.25 drives. Plug and play.

I am sure cumana will work that way too. If I remember correctly it was Oric DOS that need some kind of config?

Also, hfe is a bit stream representation, so it must support 3 inch disk images with no issues. It works for Amstrad and Spectrum, so.....

With a cumana I am quite sure you can plug 3, 3.5 and 5.25 drives and a gotek at the same time and make transfers between them all using Sedoric.

Posted: **Fri Jul 03, 2020 9:49 pm**

You can check your configuration using DSYS. Drives are usually 42 track or 82 track - single or double sided. It can be set with DTRACK.
Drives will work to some extent but if you want o format a disk it helps to have the system set up right.

I've found my way over to the Greasweazle Facebook page. They are offering a couple of types with options of fully assembled or kit. I've ordered one of the F7 v2 fully assembled. It looks a bit complicated to get it working, but I'll give it a go.
The files can be output to HFE so we're still at the point where a HFE to Dsk program is desirable.

Cumana will work with the Gotek. Cumana Reborn is a smaller version of Cumana with Gotek, isn't it? Some modern components but it's basically the same. So for me with Cumana, I need a Gotek. But with either device it's the HFE format that is the problem.

But, as I said, I hope to get a PC working which might be easier, for me, to convert floppies.

Posted: **Fri Jul 03, 2020 10:00 pm**

iss wrote: ↑Fri Jul 03, 2020 8:18 pm I think in this case the best will be PC with attached floppy (3" or 3.5" depending on the BD-DOS disks) and OmniFlop which work just fine for analyzing and reading strange floppy formats.

Thanks for this. I don't think I've come across Omniflop before. That looks interesting. I've downloaded the different versions. I must have another look at my PC !!!

Posted: **Sun Jul 05, 2020 5:33 pm**

Steve M wrote: ↑Fri Jul 03, 2020 9:49 pm You can check your configuration using DSYS. Drives are usually 42 track or 82 track - single or double sided. It can be set with DTRACK.
Drives will work to some extent but if you want o format a disk it helps to have the system set up right.

I've found my way over to the Greasweazle Facebook page. They are offering a couple of types with options of fully assembled or kit. I've ordered one of the F7 v2 fully assembled. It looks a bit complicated to get it working, but I'll give it a go.
The files can be output to HFE so we're still at the point where a HFE to Dsk program is desirable.

Cumana will work with the Gotek. Cumana Reborn is a smaller version of Cumana with Gotek, isn't it? Some modern components but it's basically the same. So for me with Cumana, I need a Gotek. But with either device it's the HFE format that is the problem.

But, as I said, I hope to get a PC working which might be easier, for me, to convert floppies.

I feel a bit stupid... somewhere along this thread I lost its point completely. Of course you already knew all of this...!

I had in mind just reading disks to convert between real disks and images in the Gotek with your Oric, I totally forgot about everything else. Even the fact that we are talking about dealing with BD-DOS disks images!.

Okay, back to the original idea. If you happen to get a PC with a real drive (not one using USB, even internally, so the geometry parameters can be configured) you can use good old WRITEDSK/READDSK under win95/DOS (which I use - I have an old laptop just for that) or Omniflop for newer operating systems (I never tried this one). The main problem is that it is less and less frequent to have a PC with a "real" floppy drive, and that is where (supposedly) Greaseweazel comes in handy.

I now very little about this project, but it seems you can connect any kind of floppy drive to it and read/write from your PC even the most strange disk geometries and produce a real dump of its low level contents. That is nice for odd formats, geometries and copy protections.

But, as you just said, we are still needing some kind of conversion from HFE to DSK, but at least the result could be tested on an oric with a Gotek...

Let me know if you end up testing Omniflop or getting your hands on a Greaseweazel

Posted: **Mon Jul 13, 2020 4:27 am**

Minor additional comments from me: since Clock Signal already supports both HFE and edsk, you could at a stretch use it as a converter but probably the more useful contribution is that I could knock up a simple command-line tool if it'd be helpful.

Only two caveats: (i) I don't support HFEv3 yet, but it'll be shortly forthcoming; and (ii) I've yet to find a good documentation of what a program reads from the WD1770 when it detects a sync word. It is known to provide spurious bytes rather than just throwing out either the current shift register value or the decoded value of the sync byte, alas. This is why Clock Signal doesn't do so well with pasti-format ST disks, though it does also attempt to support them, and they might even be a better fit for Oricutron — they actually record the results from a read track separately from those for reading sectors and if your emulator is able to just use those two bits of information separately then they're pretty easy to handle.

Posted: **Tue Feb 09, 2021 1:49 pm**

Having recently retired, I thought that I would dig out my ORIC stuff to while away some of the winter/lockdown hours in a pleasant way. I was surprised that a lot of it still worked after being in storage for about 20
years. One of my ORICs, my Cumana interface and all of the disk drives fired up without complaint. So
far, all of the SEDORIC disks which I have tried boot up nicely and offer up files.
I discovered Euphoric some years ago and I managed to copy some real disks to Euphoric disk images on a
(now long discarded) PC. Sadly, I lost many of these disk images when I upgraded my PC and old hard
drives failed (backup before you think that you need to!).

I obtained a couple of basic GOTEK drives directly from China (they were very cheap last year) and
upgraded them (usual rotary selector, nice display and sound) before programming them with the software.
I used USB ports on PC & GOTEK to do the programming. As many of you will know, there are nice Youtube
walkthroughs of these procedures.
The Gotek allowed me to transfer disk images between PC & ORIC very nicely. I wrote a program in C++ to
convert back from ".IMG" files, obtained via the HxCFloppyEmulator "Export" facility, but now the
HxCFloppyEmulator can "Export" to ORIC ".DSK" files directly.
I have written programs to extract files from a ".DSK" image on my PC and to write them back (nice and
easy to edit text in assembly language files) and to produce ASCII dump of non-text files and disk
images (easy to see what the file/image contains).

Anyway this has gone quite well and I have enjoyed working on ORIC stuff with the SEDORIC operation system.

I came acroff this "Defence Force" website a few weeks ago and was intrigued to see a thread on "Is BD-
DOS lost to time". This prompted me to look at my BD500 stuff to try and get this hardware running but, sadly, without success. Using "Nibble" on my SEDORIC system showed that my Byte Drive disks have not survived as well as the SEDORIC disks.
However, Oricutron came to my rescue and I have been able to work with the BD500 emulator, albeit using
the early V2.2 operating system.
Thankfully, I could access some of my BD500 development files which I had saved on a SEDORIC disk and I
have been working on an upgrade along the lines of DOS6/BASIC4 that some of you know. I have extended
the BD operating system to include subdirectories on the disk and I will be able to pass this on soon.

I have quite a bit of useful information which would help in the development of Oricutron for the Byte
Drive and I will pass this on in another posting very soon. Meanwhile, I would like to know how, on
Oricutron for the BD500, I can define another ROM for each of ATMOS and ORIC computer. I tried the line
"atmosrom = 'roms/basic50'" in file "oricutron.cfg" but it didn't seem to have any effect (the original ATMOS
ROM was loaded, I believe). I tried to overwrite the "basic11b.rom" file with mine (to keep the same
name) but it didn't have any effect. Perhaps the ROMS are hard-coded into Oricutron and, at the moment,
cannot be changed by the user. Any help on this would be most appreciated as I am trying to put BASIC 5
in a ROM and load DOS7 from disk at bootup. I have it set up like the original BD500 V2.2 system at the
moment and it works fine but it does gobble up quite a bit of RAM below memory address $9800.

Ray McLaughlin

Posted: **Tue Feb 09, 2021 3:06 pm**

Wow, nice to see you around

Wanted to thank you for your past work on Sedoric and documenting it with André C., it's been very helpful when I played a bit with it years ago.

I think I also had a few questions about your old software distribution in a thread a few years ago. Yes, that was here https://forum.defence-force.org/viewtopic.php?p=20237. Anyway, not sure I ever uploaded anything, life's been hectic since then -_- .

Posted: **Tue Feb 09, 2021 6:41 pm**

Welcome @Ray, it's amazing to meet you!

Ray030471 wrote: ↑Tue Feb 09, 2021 1:49 pm I have quite a bit of useful information which would help in the development of Oricutron for the Byte Drive and I will pass this on in another posting very soon.

I can wait to finish the BD500 support filling the missing functionality!

Ray030471 wrote: ↑Tue Feb 09, 2021 1:49 pm I would like to know how, on Oricutron for the BD500, I can define another ROM for each of ATMOS and ORIC computer.
I tried the line "atmosrom = 'roms/basic50'" in file "oricutron.cfg" but it didn't seem to have any effect (the original ATMOS
ROM was loaded, I believe). I tried to overwrite the "basic11b.rom" file with mine (to keep the same name) but it didn't have any effect. Perhaps the ROMS are hard-coded into Oricutron and, at the moment, cannot be changed by the user.

First, what is your host OS (Windows,Linux,...) ? What version of Oricutron are you using?
Actually for BD500 support are two options: build by yourself from sources or dev-builds from my site - both options should work fine. I think you made all changes in oricutron.cfg correct but here you are:
- put Oricutron in path without spaces (just for any case);
- if your host OS is Linux the names are case sensitive;
- copy your ROM file 'basic50.rom' (16384 bytes long) to roms/ subdirectory;
- check that you have the BD500 ROM file (8192 bytes long) in roms/ too i.e. 'roms/bd500.rom';
- put in 'oricutron.cfg' the names exactly without the 'rom' extension which will be added internally:

Code: Select all

atmosrom = 'roms/basic50'
oric1rom = 'roms/basic50'
bd500rom = 'roms/bd500'
disktype = bd500

- start Oricutron from command line - eventually to see any log messages for Windows:

Code: Select all

oricutron path_to_the_imagefile\bddos_mage.dsk

and for Linux:

Code: Select all

./oricutron path_to_the_imagefile/bddos_mage.dsk

This should work. You can add command line switches to select machine: '-ma' for Atmos or '-m1' for Oric-1.
Hope this helps and waiting for your feedback!

Posted: **Tue Feb 09, 2021 9:46 pm**

Hi Dr Ray,

Good to hear from you.
I bought Rob Kimberly's BD system. It seems a bit worn and was in storage for a good number of years.
Would you be able to post a picture of the connector from the drive to bas unit of the BD? Kimbo's connectors don't look right. I have a box of connectors that will fit but I want to be sure of getting the connections right.

Just spoke to Dave D yesterday, who has moved down to the south coast.

If I can get my BD system working I can copy some masters for you - if they work.

I'd love to know a bit more about how you got involved with the ByteDrives. Did you have anything to do with ITL Kathmill, or just got involved via BDUG?

Also interested about the Sedoric story. (Allan Whitaker rang me last year also !)

Posted: **Wed Feb 10, 2021 6:30 pm**

@Ray: I've updated Oricutron sources as suggested, thanks!

Can you please share more info about the 'mysterious' 0x317 address and its purpose?

Posted: **Fri Feb 12, 2021 11:29 pm**

Steve M wrote: ↑Tue Feb 09, 2021 9:46 pm Hi Dr Ray,

Good to hear from you.
I bought Rob Kimberly's BD system. It seems a bit worn and was in storage for a good number of years.
Would you be able to post a picture of the connector from the drive to bas unit of the BD? Kimbo's connectors don't look right. I have a box of connectors that will fit but I want to be sure of getting the connections right.

Just spoke to Dave D yesterday, who has moved down to the south coast.

If I can get my BD system working I can copy some masters for you - if they work.

I'd love to know a bit more about how you got involved with the ByteDrives. Did you have anything to do with ITL Kathmill, or just got involved via BDUG?

Also interested about the Sedoric story. (Allan Whitaker rang me last year also !)

Hi Steve.

I am using Oricutron at the moment and making good progress. I will be posting more information on my developments and some technical information for Pete Gordon so that he can update Oricutron for the Byte Drive.
I have attached a couple of picture files as you requested.

"
"Picture1.jpg", the top picture, shows a standard ITL set up. The cable shown goes from the BD interface to the floppy disk drive and the (blue) coloured wire (no 1) is on the right at both ends shown. Both connectors on the BD interface are standard and the floppy connector is a standard card-edge connector.
"Picture2.jpg" which is of a BD interface that I wired up myself shows the ORIC end of it. As you look at it, pin 1 is the one nearest to you on the bottom face of the card (you might be able to make out the red on the wire's insulation). Pin2 is the one nearest to you on the top face of the card and so on. I haven't shown it but the floppy disk end of the BD interface has odd-numbered pins (all common) on the underside and all even-numbered pins on the top with pin number 1 nearest you in the picture.
The interface in "Picture1.jpg" is neater with the standard connectors soldered to the card rather than the wires soldered directly to the card.

I became known to ITL Kathmill initially because the interface and drives which I bought from them didn't work and, as I had to go to London on business, I popped along to Chatham and appeared at their premises. They treated me very well by trying some other of their BD interfaces on my ORIC1 and soon presented me with a stable system. The nice guy who was helping me (John somebody) also slightly upgraded my old ORIC 1 (2 8k Eproms) by disconnecting the lower 8k Eprom's ROMDIS pin from its socket and wiring it to the ROMDIS pin of the other Eprom. Of course, it didn't affect the operation of the system as I saw it as a user but it did use overlay RAM for the whole of the upper 16K of address space. This is information, with more technical detail, which I will pass on to Pete Gordon very soon.

I now have my DOS7 & Basic5 working on Oricutron as it would on the real hardware, ie BASIC5 in a ROM and DOS7 booting up from the floppy disk. This is very much like the SEDORIC set up but I have completely reprogrammed BASIC and DOS with sensible (I think) separation of code. I'll be posting details of this and uploading my (current) beta version very soon so that those interested can play with it and report bugs/improvements. Over time, I will also be modifying my other software to suit (Wordspeed, Assembler, Compiler) and making that available.

Best wishes.

Ray.

Posted: **Sat Feb 13, 2021 12:24 am**

iss wrote: ↑Tue Feb 09, 2021 6:41 pm Welcome @Ray, it's amazing to meet you!

Ray030471 wrote: ↑Tue Feb 09, 2021 1:49 pm I have quite a bit of useful information which would help in the development of Oricutron for the Byte Drive and I will pass this on in another posting very soon.
I can wait to finish the BD500 support filling the missing functionality!

Ray030471 wrote: ↑Tue Feb 09, 2021 1:49 pm I would like to know how, on Oricutron for the BD500, I can define another ROM for each of ATMOS and ORIC computer.
I tried the line "atmosrom = 'roms/basic50'" in file "oricutron.cfg" but it didn't seem to have any effect (the original ATMOS
ROM was loaded, I believe). I tried to overwrite the "basic11b.rom" file with mine (to keep the same name) but it didn't have any effect. Perhaps the ROMS are hard-coded into Oricutron and, at the moment, cannot be changed by the user.
First, what is your host OS (Windows,Linux,...) ? What version of Oricutron are you using?
Actually for BD500 support are two options: build by yourself from sources or dev-builds from my site - both options should work fine. I think you made all changes in oricutron.cfg correct but here you are:
- put Oricutron in path without spaces (just for any case);
- if your host OS is Linux the names are case sensitive;
- copy your ROM file 'basic50.rom' (16384 bytes long) to roms/ subdirectory;
- check that you have the BD500 ROM file (8192 bytes long) in roms/ too i.e. 'roms/bd500.rom';
- put in 'oricutron.cfg' the names exactly without the 'rom' extension which will be added internally:
Code: Select all
atmosrom = 'roms/basic50'
oric1rom = 'roms/basic50'
bd500rom = 'roms/bd500'
disktype = bd500
- start Oricutron from command line - eventually to see any log messages for Windows:
Code: Select all
oricutron path_to_the_imagefile\bddos_mage.dsk
and for Linux:
Code: Select all
./oricutron path_to_the_imagefile/bddos_mage.dsk
This should work. You can add command line switches to select machine: '-ma' for Atmos or '-m1' for Oric-1.
Hope this helps and waiting for your feedback!

Hello.

Many thanks for this really useful information. My operating system is Windows 7 32 bit) and I am running "Oricutron_win32-20200515" which I downloaded a couple of months ago. Your site currently has this named Oricutron version for download but is it the version which you updated a few days ago?

I have managed to overcome the ROM problem which I reported and your help is much appreciated. I was doing the correct things in the config file and I found out what was actually going wrong. I was writing to the 0x313 and 0x314 addresses (managing ROMDIS and MAP simultaneously) but, when I looked at more of your source code, I realised that Oricutron didn't emulate writing to these addresses. In the real hardware, reading from and writing to these addresses have exactly the same effect. It would be nice if you could add this to Oricutron.

i now have some very important and, I believe, useful information on the other addresses in the range 0x310 to 0x317.

Address 0x310 switches the disk drive motor off. It is called MOTOFF in the ITL assembly listing.
Address 0x311 switches the disk drive motor on. It is called MOTON in the ITL assembly listing.
I think that the motor is switched on by (electronic) default on first powering up the BD interface but it is safer to switch it on in the boot sector (page 4) code.

Address 0x312, as you know is read (BIT instruction) to obtain the FDC's DRQ in bit 7 and IRQ in bit 6. It is called DSTATS in the ITL assembly listing.

Reading or writing address 0x313 enables the ORIC ROM and disables the overlay RAM. It is called MAPOFF in the ITL assembly listing.
Reading or writing address 0x314 disables the ORIC ROM and enables the overlay RAM. It is called MAPON in the ITL assembly listing.

Address 0x315, called PRECMP in the ITL assembly listing, is, I believe, for write compensation on the FDC. I think that it is used in the DOS versions V2.2 & V3.1 of the BD software but not in my latest version - perhaps I should include it.

Reading or writing address 0x316 enables the the lower 8k of the ORIC's EPprom (used where the ORIC has 2 8k Eproms) and therefore disables the overlay RAM in that memory area. This overrides MAPON (see above). It is called SDEN in the ITL assembly listing.
Reading or writing address 0x317 disables the lower 8k of the ORIC's Eprom (used where the ORIC has 1 16k Eprom or ROM) and therefore enables the overlay RAM when MAPON has been accessed. It is called DDEN in the ITL assembly listing.

Reading (or writing, I believe) address 0x380 disables the BD interface ROM which covers addresses 0xE00 to 0xFFFF but before that is done, it takes precedence over the above for that memory space.

These facilities, SDEN & DDEN, are to cater for the different ORIC hardware. The existence of 2 x 8k EPROM machines is one of the reasons for ITL to base their system on the ORIC V1.0 operating system (they couldn't mask the lower 8k Eprom without opening up each of those ORIC machines). Another reason was connected with licensing. They couldn't give the V1.1 (ATMOS) operating system to those who hadn't already bought it from ORIC but they could give the V1.0 (ORIC) operating system to those who had bought an ATMOS machine.

I hope that you find this information interesting and useful.

It would be nice of you could update Oricutron to include the writing of addresses 0x313 & 0x314 (bd->oric->romdis set as SDL_FALSE and SDL_TRUE respectively) as this would enable me to have some slicker code when windowing between ROM and RAM in the top 16k of address space (as I can with the real hardware).

I have downloaded your source code and will look into compiling it when I can. I use Microsoft's Visual Studio (C++ and VB.Net) but, at the moment, I am not sure how to compile your C code. Meanwhile, it would be nice if you could upload the latest (after doing the above) compiled code to this site or to me directly, if that is possible.

I will also be posting the above information on the Oricutron site as soon as I can but it's getting a bit late now.

Best wishes.

Ray.

Posted: **Sat Feb 13, 2021 8:33 am**

Oricutron sources updated.
Oricutron for developers updated too.

@Ray: This is great! I never expected that we will have any info about BD500.

Now it's clear for me the reason for the strange handling of 56k/64k modes:
when financiers and managers are stepping-in the source codes become weird

.

Attached you can find a ZIP file with Quadro-boot images built with my WIP-project BOOTER.

The same image can be used with Microdisk, Jasmin, BD500 and 8D-FDC (the last - 8D-FDC is not working now).
Use the DSK-image in Oricutron with command line swithces: -km, -kj, -kb to select the FDC controller type.
Use the HFE-image with Gotek emulators and any floppy controller.

drvtest.zip: (28.34 KiB) Downloaded 228 times

Waiting for any further info and feedback about BD500.

Posted: **Sat Feb 13, 2021 9:05 am**

The same image can be used with Microdisk, Jasmin, BD500 and 8D-FDC (the last - 8D-FDC is not working now).

That's... interesting, does that mean we could soon patch the FloppyBuilder based games and demos so they run on all of that?

Posted: **Sat Feb 13, 2021 10:43 am**

Dbug wrote: ↑Sat Feb 13, 2021 9:05 am
The same image can be used with Microdisk, Jasmin, BD500 and 8D-FDC (the last - 8D-FDC is not working now).
That's... interesting, does that mean we could soon patch the FloppyBuilder based games and demos so they run on all of that?

Unfortunately just binary patch will not work.
I'm writing BOOTER from scratch and the goal is to support 2 more devices which are in beta test now.
I will share the booting code and IMHO it will be not difficult to merge it with FloppyBuilder and recompile the demos and games.

Posted: **Sat Feb 13, 2021 11:47 am**

Ray030471 wrote: ↑Sat Feb 13, 2021 12:24 am
iss wrote: ↑Tue Feb 09, 2021 6:41 pm Welcome @Ray, it's amazing to meet you!

Ray030471 wrote: ↑Tue Feb 09, 2021 1:49 pm I have quite a bit of useful information which would help in the development of Oricutron for the Byte Drive and I will pass this on in another posting very soon.
I can wait to finish the BD500 support filling the missing functionality!

Ray030471 wrote: ↑Tue Feb 09, 2021 1:49 pm I would like to know how, on Oricutron for the BD500, I can define another ROM for each of ATMOS and ORIC computer.
I tried the line "atmosrom = 'roms/basic50'" in file "oricutron.cfg" but it didn't seem to have any effect (the original ATMOS
ROM was loaded, I believe). I tried to overwrite the "basic11b.rom" file with mine (to keep the same name) but it didn't have any effect. Perhaps the ROMS are hard-coded into Oricutron and, at the moment, cannot be changed by the user.
First, what is your host OS (Windows,Linux,...) ? What version of Oricutron are you using?
Actually for BD500 support are two options: build by yourself from sources or dev-builds from my site - both options should work fine. I think you made all changes in oricutron.cfg correct but here you are:
- put Oricutron in path without spaces (just for any case);
- if your host OS is Linux the names are case sensitive;
- copy your ROM file 'basic50.rom' (16384 bytes long) to roms/ subdirectory;
- check that you have the BD500 ROM file (8192 bytes long) in roms/ too i.e. 'roms/bd500.rom';
- put in 'oricutron.cfg' the names exactly without the 'rom' extension which will be added internally:
Code: Select all
atmosrom = 'roms/basic50'
oric1rom = 'roms/basic50'
bd500rom = 'roms/bd500'
disktype = bd500
- start Oricutron from command line - eventually to see any log messages for Windows:
Code: Select all
oricutron path_to_the_imagefile\bddos_mage.dsk
and for Linux:
Code: Select all
./oricutron path_to_the_imagefile/bddos_mage.dsk
This should work. You can add command line switches to select machine: '-ma' for Atmos or '-m1' for Oric-1.
Hope this helps and waiting for your feedback!
Hello.

Many thanks for this really useful information. My operating system is Windows 7 32 bit) and I am running "Oricutron_win32-20200515" which I downloaded a couple of months ago. Your site currently has this named Oricutron version for download but is it the version which you updated a few days ago?

I have managed to overcome the ROM problem which I reported and your help is much appreciated. I was doing the correct things in the config file and I found out what was actually going wrong. I was writing to the 0x313 and 0x314 addresses (managing ROMDIS and MAP simultaneously) but, when I looked at more of your source code, I realised that Oricutron didn't emulate writing to these addresses. In the real hardware, reading from and writing to these addresses have exactly the same effect. It would be nice if you could add this to Oricutron.

i now have some very important and, I believe, useful information on the other addresses in the range 0x310 to 0x317.

Address 0x310 switches the disk drive motor off. It is called MOTOFF in the ITL assembly listing.
Address 0x311 switches the disk drive motor on. It is called MOTON in the ITL assembly listing.
I think that the motor is switched on by (electronic) default on first powering up the BD interface but it is safer to switch it on in the boot sector (page 4) code.

Address 0x312, as you know is read (BIT instruction) to obtain the FDC's DRQ in bit 7 and IRQ in bit 6. It is called DSTATS in the ITL assembly listing.

Reading or writing address 0x313 enables the ORIC ROM and disables the overlay RAM. It is called MAPOFF in the ITL assembly listing.
Reading or writing address 0x314 disables the ORIC ROM and enables the overlay RAM. It is called MAPON in the ITL assembly listing.

Address 0x315, called PRECMP in the ITL assembly listing, is, I believe, for write compensation on the FDC. I think that it is used in the DOS versions V2.2 & V3.1 of the BD software but not in my latest version - perhaps I should include it.

Reading or writing address 0x316 enables the the lower 8k of the ORIC's EPprom (used where the ORIC has 2 8k Eproms) and therefore disables the overlay RAM in that memory area. This overrides MAPON (see above). It is called SDEN in the ITL assembly listing.
Reading or writing address 0x317 disables the lower 8k of the ORIC's Eprom (used where the ORIC has 1 16k Eprom or ROM) and therefore enables the overlay RAM when MAPON has been accessed. It is called DDEN in the ITL assembly listing.

Reading (or writing, I believe) address 0x380 disables the BD interface ROM which covers addresses 0xE00 to 0xFFFF but before that is done, it takes precedence over the above for that memory space.

These facilities, SDEN & DDEN, are to cater for the different ORIC hardware. The existence of 2 x 8k EPROM machines is one of the reasons for ITL to base their system on the ORIC V1.0 operating system (they couldn't mask the lower 8k Eprom without opening up each of those ORIC machines). Another reason was connected with licensing. They couldn't give the V1.1 (ATMOS) operating system to those who hadn't already bought it from ORIC but they could give the V1.0 (ORIC) operating system to those who had bought an ATMOS machine.

I hope that you find this information interesting and useful.

It would be nice of you could update Oricutron to include the writing of addresses 0x313 & 0x314 (bd->oric->romdis set as SDL_FALSE and SDL_TRUE respectively) as this would enable me to have some slicker code when windowing between ROM and RAM in the top 16k of address space (as I can with the real hardware).

I have downloaded your source code and will look into compiling it when I can. I use Microsoft's Visual Studio (C++ and VB.Net) but, at the moment, I am not sure how to compile your C code. Meanwhile, it would be nice if you could upload the latest (after doing the above) compiled code to this site or to me directly, if that is possible.

I will also be posting the above information on the Oricutron site as soon as I can but it's getting a bit late now.

Best wishes.

Ray.

I forgot another bit of information. Memory register 0x312 (DSTATS), when read, also indicates, in bit 0, whether the disk drive motor is on or off. If b0 is 0 then the motor is ON but if b0 is 1 then the motor is OFF.

I mentioned before that it would be nice of register 0x31a could be used, in addition to indicating the drive number in bits 6 & 7, to indicate the disk side in bit 5. If that is possible then, at least in the emulator, I could upgrade my DOS7 to cater for double-sided disks.

Posted: **Sat Feb 13, 2021 12:09 pm**

Ray030471 wrote: ↑Sat Feb 13, 2021 11:47 am I forgot another bit of information. Memory register 0x312 (DSTATS), when read, also indicates, in bit 0, whether the disk drive motor is on or off. If b0 is 0 then the motor is ON but if b0 is 1 then the motor is OFF.

I mentioned before that it would be nice of register 0x31a could be used, in addition to indicating the drive number in bits 6 & 7, to indicate the disk side in bit 5. If that is possible then, at least in the emulator, I could upgrade my DOS7 to cater for double-sided disks.

Well, new release again today!

Implemented are all changes so far. But I found that adding bit 0 (motor status) when reading from 0x312 hangs ver.2.2.
So I've added the option 'dos70; in 'oricutron.cfg': dos70 is by default disabled and ver.2.2 works, to enable it set in CFG file:

Code: Select all

dos70 = yes

Here is summary of all info so far:

Code: Select all

0x310 MOTOFF  R   switches the disk drive motor off.
0x311 MOTON   R   switches the disk drive motor on.
                    NOTE: (probably)the motor is switched on
                    by (electronic) default on first powering up
                    the BD interface but it is safer to switch it
                    on in the boot sector (page 4) code.

0x312 DSTATS  R   bit 7 - DRQ
                  bit 6 - IRQ
                  bit 0 - motor status (): b0=0 ON, b0=1 OFF (NOTE: DOS7 only).

0x313 MAPOFF  R/W enables the ORIC ROM and disables the overlay RAM.

0x314 MAPON   R/W disables the ORIC ROM and enables the overlay RAM.

0x315 PRECMP  R   (probably) forwrite compensation on the FDC.
                    NOTE: maybe it's used in the DOS versions V2.2 & V3.1
                    of the BD software but not in Ray's latest version,
                    perhaps it will be included.

0x316 SDEN    R/W enables the the lower 8k of the ORIC's EPROM
                  (used where the ORIC has 2x8k EPROMS) and therefore
                  disables the overlay RAM in that memory area.
                  This overrides MAPON (see above).

0x317 DDEN    R/W disables the lower 8k of the ORIC's EPROM
                  (used where the ORIC has 1x16k EPROM or ROM)
                  and therefore enables the overlay RAM when MAPON
                  has been accessed.

0x31a DRVSEL  R   bit 7,6 - current drive
                  bit 5   - current side
              W   bit 7,6 - select drive
                  bit 1   - select side

0x0380        R/W disables the BD interface ROM which covers addresses
                  0xE000 to 0xFFFF but before that is done, it takes
                  precedence over the above for that memory space.

Please update if something is wrong. I'm ready to push new versions on every changed bit

Posted: **Sun Feb 14, 2021 5:16 pm**

iss wrote: ↑Sat Feb 13, 2021 12:09 pm
Ray030471 wrote: ↑Sat Feb 13, 2021 11:47 am I forgot another bit of information. Memory register 0x312 (DSTATS), when read, also indicates, in bit 0, whether the disk drive motor is on or off. If b0 is 0 then the motor is ON but if b0 is 1 then the motor is OFF.

I mentioned before that it would be nice of register 0x31a could be used, in addition to indicating the drive number in bits 6 & 7, to indicate the disk side in bit 5. If that is possible then, at least in the emulator, I could upgrade my DOS7 to cater for double-sided disks.
Well, new release again today!

Implemented are all changes so far. But I found that adding bit 0 (motor status) when reading from 0x312 hangs ver.2.2.
So I've added the option 'dos70; in 'oricutron.cfg': dos70 is by default disabled and ver.2.2 works, to enable it set in CFG file:
Code: Select all
dos70 = yes
Here is summary of all info so far:
Code: Select all
0x310 MOTOFF  R   switches the disk drive motor off.
0x311 MOTON   R   switches the disk drive motor on.
                    NOTE: (probably)the motor is switched on
                    by (electronic) default on first powering up
                    the BD interface but it is safer to switch it
                    on in the boot sector (page 4) code.

0x312 DSTATS  R   bit 7 - DRQ
                  bit 6 - IRQ
                  bit 0 - motor status (): b0=0 ON, b0=1 OFF (NOTE: DOS7 only).

0x313 MAPOFF  R/W enables the ORIC ROM and disables the overlay RAM.

0x314 MAPON   R/W disables the ORIC ROM and enables the overlay RAM.

0x315 PRECMP  R   (probably) forwrite compensation on the FDC.
                    NOTE: maybe it's used in the DOS versions V2.2 & V3.1
                    of the BD software but not in Ray's latest version,
                    perhaps it will be included.

0x316 SDEN    R/W enables the the lower 8k of the ORIC's EPROM
                  (used where the ORIC has 2x8k EPROMS) and therefore
                  disables the overlay RAM in that memory area.
                  This overrides MAPON (see above).

0x317 DDEN    R/W disables the lower 8k of the ORIC's EPROM
                  (used where the ORIC has 1x16k EPROM or ROM)
                  and therefore enables the overlay RAM when MAPON
                  has been accessed.

0x31a DRVSEL  R   bit 7,6 - current drive
                  bit 5   - current side
              W   bit 7,6 - select drive
                  bit 1   - select side

0x0380        R/W disables the BD interface ROM which covers addresses
                  0xE000 to 0xFFFF but before that is done, it takes
                  precedence over the above for that memory space.
Please update if something is wrong. I'm ready to push new versions on every changed bit

Your response time is super. Many thanks

I have downloaded your latest version, Oricutron_win32-20210213.zip, and it runs well.

I have found that by choosing the "dos70=yes" option in the config file when running DOS7 leads to "Drive Error" which might mean that the motor is switched off.
However, dos70=no" gives normal operation when running DOS7 and so I will run with that - no need as yet for me to read to find out if the motor is running.
A little mystery to be solved at some point, perhaps.

I wasn't clear enough about my request concerning disk side (head). Please could you change the writing of 0x31a (DRVSEL) to
W bit 7,6 - select drive
bit 5 - select side

I can then ROR in the carry flag (suitably set, of course).

Leave the read as it is but I'm not sure if the actual hardware has read access.

When that is done, I can start on development of DOS7.0 to cater for double-sided disks.

There is no great rush on my part but please can you post the link to the new download when it is done.

Best wishes.

Ray.

mplemented are all changes so far. But I found that adding bit 0 (motor status) when reading from 0x312 hangs ver.2.2.

Posted: **Sun Feb 14, 2021 8:14 pm**

@Ray: 0x31a (DRVSEL) updated! Oricutron download as usual

.

Posted: **Tue Feb 16, 2021 2:24 pm**

Ray030471 wrote: ↑Fri Feb 12, 2021 11:29 pm
I have attached a couple of picture files as you requested.

Thanks. It was the power connection at the back that I'm not sure of, rather than the hybrid.

Ray030471 wrote: ↑Fri Feb 12, 2021 11:29 pm I became known to ITL Kathmill initially because the interface and drives which I bought from them didn't work and, as I had to go to London on business, I popped along to Chatham and appeared at their premises. They treated me very well by trying some other of their BD interfaces on my ORIC1 and soon presented me with a stable system. The nice guy who was helping me (John somebody) also slightly upgraded my old ORIC 1 (2 8k Eproms) by disconnecting the lower 8k Eprom's ROMDIS pin from its socket and wiring it to the ROMDIS pin of the other Eprom. Of course, it didn't affect the operation of the system as I saw it as a user but it did use overlay RAM for the whole of the upper 16K of address space. This is information, with more technical detail, which I will pass on to Pete Gordon very soon.

It seems a common problem that the drives, or cables, had issues.
The Astrosyn boss was John Melville. Might have been him?

Ray030471 wrote: ↑Fri Feb 12, 2021 11:29 pm I now have my DOS7 & Basic5 working on Oricutron as it would on the real hardware, ie BASIC5 in a ROM and DOS7 booting up from the floppy disk. This is very much like the SEDORIC set up but I have completely reprogrammed BASIC and DOS with sensible (I think) separation of code. I'll be posting details of this and uploading my (current) beta version very soon so that those interested can play with it and report bugs/improvements. Over time, I will also be modifying my other software to suit (Wordspeed, Assembler, Compiler) and making that available.

I think DOS6 and Basic 4 is the most recent I have. I have Wordspeed but I think it is an earlier version than the Sedoric one.
I'm a bit confused as to which versions worked with the FORMAT command as some seem to need an earlier version for it to work. But still - I need to get the hardware sorted first.

Posted: **Tue Feb 16, 2021 9:01 pm**

Hello again.

Here are some more pictures, this time from the back of the disk drive (BD500 40 track, single sided).

"ByteDrive FDC.jpg"

shows where the hybrid cable (or cable from Cumana board) connects. The numbering is there and you can see that the even numbers are on the top, with 2 on the left, and therefore the odd numbers are on the bottom.
"ByteDrive Cable.jpg"

shows the hybrid cable attached ( I looped the cable under the drive for easier viewing). You can just about make out the blue strip which, here, indicates wire 1. This cable would only fit one way with wire 1 where it is indicated on the disk drive. I haven't tried it out live but I believe that this is correct.
"ByteDrive Power.jpg"

shows the underside of the disk drive where the standard power connector fits and you can read the voltages.

I hope that this helps.

best wishes.

Ray.

Posted: **Tue Feb 16, 2021 10:50 pm**

Thanks. Sorry if I wasn't clear. It's the power connector I'm looking for. From the drive to the base unit. There should be a little short connector.4 wires.

Posted: **Wed Feb 17, 2021 3:48 pm**

The power connectors (4 wires) are standard PC power cables, male at one end and female at the other end.
5 1/4" drives with inbuilt power supply can be used to connect directly to the BD 3" drive power input.
The "ByteDrive Power.jpg" picture (underside view) tells you where the BD disk drive expects 12v, 5v and 0v if you need to test.

Posted: **Wed Feb 17, 2021 8:40 pm**

Hi.

Here is some more of the BD500 history.

The story of the rise and demise of itl kathmill.pdf: (1.15 MiB) Downloaded 269 times

This was written by Jeremy P. Hibbins, who ran the Byte Drive Users Group

BYTE DRIVE 500 PRICE LIST.pdf: (2.91 MiB) Downloaded 354 times

The price list I received from ITL Kathmill. Notice that it includes prices for a BD500 for the beep. As far as I know, this was newer released.

Posted: **Mon Sep 20, 2021 7:14 am**

Ray030471 wrote: ↑Tue Feb 16, 2021 9:01 pm...

@Ray030471: Hello, Ray! Any updates on BDDOS

Posted: **Mon Jan 03, 2022 9:26 pm**

I've been doing other things for a while but I have made some progress on BDDOS. I have produced a new version of BD Basic and DOS. This new DOS allows for disk directories and includes instructions such as MKDIR, CHDIR & RMDIR. I am testing this but if there is enough interest then I will make a suitable ".DSK" and (mini) manual available via this site.

Posted: **Mon Jan 03, 2022 11:48 pm**

Everything is of big interest, even just short message with status update from time to time

.

Posted: **Wed Feb 16, 2022 12:24 am**

I am still working on this, currently trying to include fields in random access file records. It is often a case of 2 steps forward and 1 step backwards when trying to squeeze code and buffers into 2 x 16k.

Posted: **Tue Feb 22, 2022 6:01 pm**

Good to hear the project is still alive.
Keep us informed !

I need to find time to get my BD up and running.

Posted: **Fri Mar 25, 2022 3:40 pm**

I am making good progress with the BD500 operating system. Fields in random access files seem to operate well.
I am now working on FORMAT. However, I am having a little difficulty in understanding how the emulator handles the fundamental FDD commands to "RESTORE" to track 0 when the next access is to side 1 (as opposed to side 0), and "STEP IN" (both sides of the disk). Any help here would be much appreciated.
In the emulator, formatting generates 80-track, double-sided disks (the maximum size?) and the BD500 DOS manages smaller sizes. With the actual hardware, FORMAT will follow the drive specification.
Once I get FORMAT done, I will include COPY (file by file) and BACKUP (track by track for the whole disk). BACKUP on the emulator will present similar "RESTORE" and "STEP IN" challenges.

Posted: **Sat Mar 26, 2022 2:28 pm**

Sounds good.
Do you know anyone with info on the cable/ interface? I know someone over on Facebook that has BD but no cable. At least one of mine is faulty.
If anyone had circuit diagram we might be able to recreate one.

I believe Jeremy at the BDUG had problems building hybrids. I don't know what happened to what stock he had. As far as I can gather he has passed away so I'm not sure if we have any chance acquire any info or old stock. Peter Halford may be the only other lead - I'm not sure what happened to him? I'm not sure if you only worked on the software(?)

Posted: **Sat Mar 26, 2022 2:55 pm**

Ray030471 wrote: ↑Fri Mar 25, 2022 3:40 pmI am making good progress with the BD500 operating system.

Amazing! I can't wait to test anything related to BD-DOS

.
About the emulator: don't use it as reference, there is no guarantee that it behaves as real hardware.
If you need something to be changed for test or any other purpose I'll do it asap.

Posted: **Mon Mar 28, 2022 5:07 pm**

I only worked on the software but if anyone has a spare Cumana disk interface then I believe that I could modify it to BD500 specifications. I don't want to modify my own Cumana disk interface just in case I couldn't revert to standard.

Posted: **Mon Mar 28, 2022 5:21 pm**

Not that long ago, somebody was selling Cumana disk controllers, can't remember whom :-/

Posted: **Tue Mar 29, 2022 3:01 pm**

I have the Cumana interface circuit boards (from Steve Hopps).
Just need to solder them together!
I 've got most of the components but work on soldering has stalled due to lack of time. And I'm not that great at electronics.

Posted: **Mon Apr 04, 2022 12:07 pm**

I could do one of those boards. I have a FDC1793 chip (probably ok) and some of the others required but a little help here also would be appreciated.

Posted: **Mon Apr 04, 2022 4:23 pm**

Cumana used the 8877 chips - I have lots of them. There's a sight difference. A couple of external components required, I think.

Posted: **Mon Apr 04, 2022 8:20 pm**

I've had a closer look at my FDC board and realised that there are two different circuit designs. It appears that I have one which was produced by the "ORIC RESEARCH CENTRE". I hadn't realised that there was much of a difference until now - thanks for alerting me to this.

Posted: **Sun Feb 12, 2023 7:21 pm**

I'm back online again after several months of being very busy doing other things.

I am trying to finalise my latest version of DOS & BASIC for the BD500 system. Hopefully, I will be able to post a disk image very soon.
I am also working out a way to boot this DOS/BASIC up via SEDORIC (running with a CUMANA or ORIC disk interface) so that many more users can have a go.

Has anyone got a disk image of my BASIC 4.0? If I remember correctly, it included a few different character set fonts.

Please watch this space.

Posted: **Tue May 09, 2023 9:51 am**

This post is from a while back - but in reply, I don't have disk image, but do have the physical disk(s). I think Rob K had an extension board on his Oric-1 with Basic Rom which may have been Basic 5? I've never yet had time to look at this system and see what works.
I might try and copy the files on the Cumana system - but I'm not sure I have a working 3".

Posted: **Mon May 15, 2023 3:11 pm**

Ray030471 wrote: ↑Sun Feb 12, 2023 7:21 pm I'm back online again after several months of being very busy doing other things ...
Please watch this space.

Any news?

Posted: **Tue May 16, 2023 2:45 pm**

I'm still making some minor adjustments and carrying out testing. Also, I am compiling manuals for the new BASIC and associated Compiler etc.
This new BASIC will include, amongst other new things, subdirectories and a well-managed FIELD structure for random access files.

I hope to post a working ".dsk" file or two very soon.

Please drop me a reminder from time to time if you wish.

Posted: **Tue May 16, 2023 3:59 pm**

Ray030471 wrote: ↑Tue May 16, 2023 2:45 pm I hope to post a working ".dsk" file or two very soon.
Please drop me a reminder from time to time if you wish.

This is very cool and I'm eager to play with it! Also I'm working on new hardware which will easily support BD-DOS too

.

forum.defence-force.org

Is BD-DOS lost to time?

Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?

Re: Is BD-DOS lost to time?