Jump to content
31336haxx0r

Any info on Video Technology Laser 500 computer?

Recommended Posts

There are some behaviour of the FDC that I cannot infer from just looking at what the ROM/DOS code does.

 

@deepfb , can I have your help in exploring the state of the FDC registers in various situations?

You'd only need to type a few BASIC commands on a Laser 700, no need for an actual floppy disk drive icon_smile.gif

 

First, I'd like to know the state of the status register when no drive is selected.

With no drive attached, after power up, type:

PRINT HEX$(INP(&H12))
What value is returned?

 

Next, I would like to know whether the FDC returns data when a drive is selected, but none is present, or no disk is inserted.

The following program will:

- Write 0xbb in the FDC data buffer

- Read data register and print the value (should be 0xbb)

- Read and print the value of the status register while idle

- Select 8-bit mode

- Select drive 1 in read mode

- Read the status register and print its value, and immediately do the same for the data register

- Put the FDC back in idle state

10 OUT &H13, &HBB
20 PRINT HEX$(INP(&H13))
30 PRINT HEX$(INP(&H12))
40 OUT &H11, &H00
50 OUT &H10, &H50
60 STOP
70 PRINT HEX$(INP(&H12))
80 PRINT HEX$(INP(&H13))
90 OUT &H10, &H00
RUN this program, it will break execution at line 60; wait for about 10 seconds (to leave ample time for the FDC to return data) and type CONT to resume execution.

What values are printed during execution?

 

That's all I have in mind for now, but that would help further document the FDC I/O registers and its inner workings. Feel free to try more stuff if you have some ideas icon_smile.gif

Share this post


Link to post
Share on other sites

Hope this helps you:

 

45578950262_31837fd336.jpg

 

44715909635_f701c84feb.jpg

 

 

On to a different matter, I have noticed that Apple II drives work on Laser 700, *but only when reading disks*: they fail when trying to write. I have been looking for the Laser 700 manual you refer on this thread, but I can't find it. I belieive there is a pinout of the floppy connector on it, isn't it? Do you know where can I download it?

  • Like 1

Share this post


Link to post
Share on other sites

@Bonstra the manual has the pinout for the Laser 700 builtin interface, see the attached file. BTW, how did you connect the laser to the Apple ][ drive?

 

And, I hadn't noticed there were different version of the DOS!! What a surprise!

I rechecked the disks and it seems we have three different versions 17/01/86, 01/05/86, 21/05/86:

 

- disk 1: DOS V1.1 good dated 21.05.86
- disk 2: DOS V1.0 good dated 01.05.86
- disk 3: DOS V1.1 corrupt dated 21.05.86 (same as disk #1 but corrupt)
- disk 4: DOS V1.0 good dated 17.01.86 (same as disk #7)
- disk 5: NO DOS
- disk 6: NO DOS (corrupt)
- disk 7: DOS V1.0 good dated 17.01.86 (same as disk #4)

I will look forward for you reverse engineering work so I can integrate it in the emulator and possibly build an hardware interface (@Piero Andreini is working on that but we are stuck replicating the controller's Toshiba gate array chip).

 

Btw, have you figured out what is the rotation speed of the disks? Is it the same as Apple? I would like to emulate the physical rotation because at the present moment the sectors are all "packed" at the start of the track without the spacing in between that comes from rotation.

post-31739-0-71546600-1540901686_thumb.jpg

  • Like 1

Share this post


Link to post
Share on other sites

I will look forward for you reverse engineering work so I can integrate it in the emulator and possibly build an hardware interface (@Piero Andreini is working on that but we are stuck replicating the controller's Toshiba gate array chip).

 

Btw, have you figured out what is the rotation speed of the disks? Is it the same as Apple? I would like to emulate the physical rotation because at the present moment the sectors are all "packed" at the start of the track without the spacing in between that comes from rotation.

I attached a datasheet of the Toshiba gate array I found while searching for info about the FDC, not sure if that will actually be of help

 

The rotation speed of the FD-100 is about 300 RPM, as shown in this video:

 

Last week-end, I finished writing a working prototype emulating the FDC and FDD down to the bit cell level.

You can find it here: https://github.com/Bonstra/laser500emu/tree/experimental-accurate-fdc

 

It is read-only for now, but disassembling the DOS routines should help understand how the FDC works in write mode.

Drag and drop a 160K .dsk file on the FDD0 rectangle in the bottom-left corner to convert the disk image to bit cells and load it into the virtual drive. Generating a .dsk back from the in-memory bit cells is not yet implemented (and would not always be possible, depending on how the disk is formatted).

 

Hope this helps you:

 

On to a different matter, I have noticed that Apple II drives work on Laser 700, *but only when reading disks*: they fail when trying to write. I have been looking for the Laser 700 manual you refer on this thread, but I can't find it. I belieive there is a pinout of the floppy connector on it, isn't it? Do you know where can I download it?

It does help, thanks, though I'm quite surprised at those results.

I was expecting the value read back from register 13h while idle to be identical to the one written beforehand.

Also, bit 1 and 4 of register 12h are set, while they are marked as unused in the manual.

 

About the manual, I own a physical copy, in a badly-translated-from-English French. I am not aware of any digital copy available for download. I started digitizing the book a while ago and have yet to complete that task.

TC1xGxxx.pdf

post-63190-0-24636000-1540932340_thumb.png

Share this post


Link to post
Share on other sites

Thank you for the information, @Bonstra and @nippur72 :)

 

the manual has the pinout for the Laser 700 builtin interface, see the attached file. BTW, how did you connect the laser to the Apple ][ drive?

I just attached different Apple II disk drives to the Laser 700 and they worked fine, even better than the FD100 when reading disks -the FD100 is buggy, it doesn't grab the disk properly so it does not spin steady.

 

But yesterday I tried to format and write to a disk, and all the Apple drives failed, they reported the disks were protected, and they weren't -I tested 5.25" and 3" drives.

 

...And the only difference is pin 9, as you told me before. It is side selection on the Laser, and -12V on Apple II. I will take a further look on it next weekend.

 

Btw, congratulations on your finds on how the Laser works!

Edited by deepfb

Share this post


Link to post
Share on other sites

@Bonstra great about the bit level emulation, I forgot to tell that I have a C tool that converts from .dsk to bit level and vice versa (the bit level file format is called ".nic"). I used it to convert @deepfb disks for the emulator. You can find it attached.

To make FDC emulation even more accurate I think we need a global time counter (derived from clock) in order to take into account the spinning of the disk.

If I am not wrong: 300 RPM => 5 rps. One bit-level track is 8192 bytes (65536 bits) => 65536 / 5 = 13107.2 bits per second.

Regarding the manual, @Hasan Batto from the facebook group has an english version and he said he's committed to scan it in the future (he already scanned the DOS manual).







sdisk2util.rar

Share this post


Link to post
Share on other sites

We have the real charset ROM dump! Tonino Bisazza extracted it from a Laser 500 he was repairing.

We discovered there are two additional charsets, GERMAN and FRENCH with their relative special letters.

Apparently the choice of the charset is hardwired (see the circuit diagram lines CGA11 and CGA12) but there is also a pin named GT (graphic table?) coming out the video chip that is involved in the selection of the set (I don't understand how though). I wonder whether there is an undocumented feature that is able to switch the charset via software.


45280087_698679710504397_492882028323563

45395541_698689623836739_593798544857917

  • Like 2

Share this post


Link to post
Share on other sites

We have the real charset ROM dump! Tonino Bisazza extracted it from a Laser 500 he was repairing.

Those are great news! Congrats!

 

We discovered there are two additional charsets, GERMAN and FRENCH with their relative special letters.

 

Apparently the choice of the charset is hardwired (see the circuit diagram lines CGA11 and CGA12) but there is also a pin named GT (graphic table?) coming out the video chip that is involved in the selection of the set (I don't understand how though). I wonder whether there is an undocumented feature that is able to switch the charset via software.

On my Laser 500 peritel (French variant), the straps for CGA11 and CGA12 are inverted; CGA11 is always 1, and CGA12 is the opposite of GT.

I remember I did test the GT output. It outputs 0 in text mode and 1 in graphics mode (I don't remember exactly which modes I tested, must be GR0 or GR1).

 

So the charset selection depending on CGA11 and CGA12 input values :

            CGA12    CGA11
English       0        0
GRx (GT=1)    0        1
German        1        0
French        1        1

BTW, the ROM dump file is 16KB but the 2764 is a 8KB ROM chip; the dump must have been done using the wrong chip size, which is why the first half of the file is filled with 0xFF. They can be safely discarded.

Edited by Bonstra

Share this post


Link to post
Share on other sites

On my Laser 500 peritel (French variant), the straps for CGA11 and CGA12 are inverted; CGA11 is always 1, and CGA12 is the opposite of GT.

I remember I did test the GT output. It outputs 0 in text mode and 1 in graphics mode (I don't remember exactly which modes I tested, must be GR0 or GR1).

 

do you have any clue what the GT signal does? It might be related to the data contained in the second charset (CGA12=0, CGA11=1). It's not an actual charset but contains all binary numbers repeated 8 times. E.g. at the position of character n. 23 it's the number 23 repeated 8 times. Maybe the use it as a sort of indexing in graphic mode, but I don't see why they had to add this over complication.

 

Another question: do you have a QWERTY layout on your keyboard? And if you have a different one (QZERTY or perhaps AZERTY) do you know how the machine is able to handle the different layout? Is that done in hardware or via software using a different ROM ?

Share this post


Link to post
Share on other sites

do you have any clue what the GT signal does? It might be related to the data contained in the second charset (CGA12=0, CGA11=1). It's not an actual charset but contains all binary numbers repeated 8 times. E.g. at the position of character n. 23 it's the number 23 repeated 8 times. Maybe the use it as a sort of indexing in graphic mode, but I don't see why they had to add this over complication.

This is a clever trick to reuse the same decoding circuits as text mode for graphic modes (maybe not for GR0 and GR3, because they work differently).

In text mode (GT = 0), to print a 8-pixels line of the character you want, the video hardware will read the character code from DRAM. Then, the hardware will output the character code to address lines CGA10-CGA3 of the chargen ROM (CGA2-CGA0 are set to the 3 lower bits from the raster line counter) and read the pixel values at that address.

 

In graphic modes GR1, GR2, GR4 and GR5, the hardware will access the DRAM the same way as it does for text mode, the only difference being that the byte read from DRAM is not a character code, but the actual pixel values you want to display.

So, the hardware sets GT = 1 in graphics mode (it is possible that GT simply reflects the value of bit 3 written in the mapped I/O region of bank 2), which causes chargen ROM data to be read starting from address 0x800 instead of 0x000 (for English variant).

The bytes in region 0x800-0xbff mirrors the address bits CGA10-CGA3, which in graphics mode is the pixel data to render (instead of a character code).

So in the end, the hardware will use the same pixel values as the ones read from DRAM, without any timing difference or additional hardware needed.

The bytes are repeated 8 times so that the same value is output, independently of CGA2-CGA0 bits.

 

Another question: do you have a QWERTY layout on your keyboard? And if you have a different one (QZERTY or perhaps AZERTY) do you know how the machine is able to handle the different layout? Is that done in hardware or via software using a different ROM ?

The keyboard on my Laser 500 is an AZERTY layout.

I checked the BASIC ROM I dumped from my Laser 500 against the one included in your emulator; they are identical.

 

If you look closely at the schematics, where the keyboard matrices for the English, French and German variants are depicted, you'll notice that on the AZERTY and QWERTZ matrices, there is a dot on line KA5, which permanently connects KA5 and KD5 for AZERTY, KA5 and KD4 for QWERTZ, and nothing at all for QWERTY (I didn't notice those dots until now).

I didn't look the code in the BASIC ROM, but I assume this is how the BASIC knows how to translate keyboard scan codes to character codes.

Share this post


Link to post
Share on other sites

cool! another two little secrets we discovered about this machine!!!

 

So the keyboard is customized via hardware, which makes sense because if you want make layouts 100% compatible and not rely on ROM for decoding. The ROM routine reads from mapped I/O: rows are on the address bus and columns on the data bus. The extended key works a little different because they added them later and they were out of address lines. The Laser 350 was meant to fit in a 310 case without the extended keys ( indeed you can move the cursor via [CTRL]+[M] [,] [.] [space] as in Laser 310).

Edited by nippur72

Share this post


Link to post
Share on other sites

@Bonstra do you know whether the ROM disk routines use any RAM memory locations apart from the relocatable disk buffers? I'm trying to assess if they can be reused in a CP/M setup where all the 4 banks would be mapped to RAM. So I need them to be "sandboxed" and not write in RAM other than the buffers.

Share this post


Link to post
Share on other sites

@Bonstra do you know whether the ROM disk routines use any RAM memory locations apart from the relocatable disk buffers?

To the best of my knowledge, apart from the buffers, the ROM routines will read and write to its own variables at logical address 0x86xx (current track, number of retries left, images of FDC registers, ), and the stack, of course. But that's about it.

They do not do any bank switching either.

 

If you want to check yourself, below is a list of the FDC-related functions I found inside the ROM.

0x00006924 boot_floppy
0x00006975 fdc_detect
0x00006980 fdc_read_sector
0x0000699d fdc_read_sector_data_part
0x00006a1e fdc_find_sector
0x00006a93 fdc_read_byte
0x00006a9b fdc_read_shifted_pair
0x00006ab3 fdc_seek_forward
0x00006ae2 fdc_seek_back
0x00006b0f fdc_set_stepper_phase
0x00006b1a fdc_enable
0x00006b21 fdc_deselect
0x00007fda fdc_get_latch_image_addr

Share this post


Link to post
Share on other sites

If you look closely at the schematics, where the keyboard matrices for the English, French and German variants are depicted, you'll notice that on the AZERTY and QWERTZ matrices, there is a dot on line KA5, which permanently connects KA5 and KD5 for AZERTY, KA5 and KD4 for QWERTZ, and nothing at all for QWERTY (I didn't notice those dots until now).

I didn't look the code in the BASIC ROM, but I assume this is how the BASIC knows how to translate keyboard scan codes to character codes.

 

yes this is correct. I tried to (un)set the bit KA5/KD5 and KA5/KD4 in the emulator and indeed keys are interpreted differently (AZERTY or QZERTZ). The check is done once at boot time (routine at 0x0af5 in ROM). The following locations are updated:

85FB bit 1-0: 00 = QWERTY keyboard layout
              01 = AZERTY keyboard layout
              10 = QWERTZ keyboard layout
85EA      (word) keyboard table layout: 06de (eng), 07da (fre), 08d6 (ger)
85EC      (word) keyboard table layout: 06de (eng), 07da (fre), 08d6 (ger) + 54h
85EE      (word) keyboard table layout: 06de (eng), 07da (fre), 08d6 (ger) + 54h + 54h

 

Share this post


Link to post
Share on other sites

Thanks!

 

I noticed a few things about my Laser 500 with AZERTY layout. In default mode the numeric keys are obtained unshifted as opposed to how they're printed on the keycaps.

 

?PEEK(&H85FB) => 9

?PEEK(&H85EA)+PEEK(&H85EB)*256 => 2010 ($07DA)

?PEEK(&H85EC)+PEEK(&H85ED)*256 => 2094 ($082E = $07DA + $54)

?PEEK(&H85EE)+PEEK(&H85EF)*256 => 2178 ($0882 = $07DA + 2 * $54)

 

So far so good.

 

POKE &H85FB,8

This causes me to remain with AZERTY layout, but the numeric keys now require SHIFT to be obtained, just like it is printed on the keycaps.

 

POKE &H85FB,9

This restores the layout to the original one.

 

The same goes for values 10 and 11 respectively, i.e. it is the LSB that in AZERTY mode toggles how numeric keys should be read.

 

This programs shifts me to QWERTY layout:

 

10 DATA 222,6,50,7,134,7
15 FOR I=0 TO 5:READ B:POKE &H85EA+I,B:NEXT
20 POKE &H85FB,8
In QWERTY mode, POKE &H85FB,9 or POKE &H85FB,10 doesn't seem to make any difference to how the keys behave.

 

I also tried to switch it to German QWERTZ mode and found that the LSB in $85FB makes no difference there as well, pretty much as expected.

Edited by carlsson
  • Like 1

Share this post


Link to post
Share on other sites

Interesting topic.

 

I've fixed a couple of the many bugs in MAME's emulation of the laser500 etc.

 

- The new character generator has been added, replacing the old inaccurate one.

- A language selection feature has been added: English (default), French, German.

- The non-working cursor keys have been fixed.

 

These will be in the next release (0.205) due out on the 26th of this month.

 

There's still plenty of other bugs, for example if you select the new language then choose the Reset option, it crashes. So, after choosing the new language, you have to quit and restart the emulator.

 

I do not possess either a machine or any manuals or software, so if you guys want other things fixed, you'll have to supply me with at least full manuals.

Share this post


Link to post
Share on other sites

Hi Robbert, nice to read you here too (I'm the mamedev issue submitter) and thank you for the fixes in MAME.

As for the manual the are at least two users we know of that own a copy. The biggest problem is that's it's difficult to scan due the way it's bound. But I'm confident we'll solve that soon or later. I'm also looking into getting a copy myself.

In the while, there are snaphsots of the schematics that you can find here: https://drive.google.com/open?id=108k-s7g2pb52nyKRjnACIzY2hFxgtLCD

IMO the next big thing that needs to be fixed in MAME is emulation speed. It's actually faster than the real machine because MAME does not emulate the extra wait states the video chip puts on the CPU. The fix is very easy: one extra z80 T-state for every memory read/write or I/O in/out.

I have two real machines and have done lots of tests to match the exact speed for my JavaScript-based emulator (https://nippur72.github.io/laser500emu/) which is now pretty accurate.

Another fix is that actual PAL frame rate is not 50 Hz but 49.7 Hz.

There is still uncertainity about the actual CPU speed, I don't have an oscilloscope, but I measured it experimentally to be 3.6702 MHz and not 3.6947 as stated in the manual (which in turn affects the PAL frame rate).

I can you give also details I found experimentally about the geometry of the video frame (number of lines, border top etc).

We also have a software emulation for the floppy disk drive interface, thanks to the big reverse-engineering work of @Bonstra. We are able to run the DOS on the JavaScript emulator, it would be nice if we could do that in MAME.












Share this post


Link to post
Share on other sites

Yeah there's plenty to do, that's for sure. MAME currently has no method to manage wait states, so the cassette problem won't be going away any time soon.

 

Here's some fixes for 0.206 (release due on 2019-01-30), these being

- Fixed the crash on reset

- connected up the cart slot. The z88dk guy will be able to experiment to his heart's content. We allow a single cart of any size up to 64k.

- Added printer and joystick

 

I'm taking a break for a bit due to an extended heatwave here, but I'll get back to it once the weather settles down.

 

So, keep an eye on this thread every now and then, when I'm ready I'll start asking questions.

 

Thanks for the schematic, just downloaded it. :)

Edited by Robbbert

Share this post


Link to post
Share on other sites

Thank you for the patches!

As for the wait states, in my emulator I have a per-instruction CPU emulation, so I simply add the number of memory reads/writes to total count of instruction's T-states.

Share this post


Link to post
Share on other sites

Hi Bonstra, Nippur72, et al.

 

- there is some uncertainty about the I/O registers: I don't know what the 16 bit mode does

 

Going through the disk formatting code(see below) in DOS 1.0, the "8/16" register appears to enable/disable "self-syncing" bytes.

 

I don't think "16" is correct, but rather 10 bit bytes are written to the disk output stream.

8 data bits of $FF plus two extra zero bits.

After reading 5 of these "self-sync" bytes, the controller is guaranteed to be "locked on" to the incoming bytes.

(See the beneath apple dos book for more info).

 

Self-sync bytes appear to be *disabled* when write mode is turned on.

Writing a $FF to port $11 turns 10 bit self-sync mode *ON*.

Writing anything but $FF to port $11 turns the self-sync mode *OFF*, and returns to writing 8 bit bytes.

 

Regards,

Leslie

 

 

 

RAM:6634 FORMAT_DISK: ; CODE XREF: RAM:65DF↑p
RAM:6634 CD E0 7B call SELECT_DRIVE ; format 40 track disk. Zero all sectors
RAM:6637 3E 11 ld a, 11h
RAM:6639 FD 77 14 ld (iy+14h), a
RAM:663C AF xor a
RAM:663D FD 77 11 ld (iy+11h), a
RAM:6640 FD 77 7F ld (iy+7Fh), a ; start at Track/Sector 0/0
RAM:6643 FD 77 7E ld (iy+7Eh), a
RAM:6646 FD 7E 7D ld a, (iy+7Dh)
RAM:6649 FD 77 7C ld (iy+7Ch), a ; Volume #
RAM:664C 06 28 ld b, 40
RAM:664E CD CA 78 call STEP_HEAD_OUT
RAM:6651 3E 0E ld a, 14 ; Set initial gap between sectors at 14 bytes of $FF
RAM:6653 32 5B FE ld (SECTOR_GAP), a
RAM:6656
RAM:6656 format_track: ;
RAM:6656 06 7F ld b, 127
RAM:6658 0E 10 ld c, 16 ; 16 sectors per track
RAM:665A 16 FF ld d, 0FFh
RAM:665C FD 7E 43 ld a, (iy+43h)
RAM:665F E6 BF and 0BFh ; 10111111 - turn on *WRREQ bit 6
RAM:6661 FD 77 43 ld (iy+43h), a ; Save copy of LATCH register
RAM:6664 D3 10 out (10h), a ; turn on *WRREQ
RAM:6666 7A ld a, d ; D = $FF here
RAM:6667 D3 13 out (13h), a
RAM:6669
RAM:6669 loc_6669: ; PC_START+670B↓j
RAM:6669 CD 64 78 call WRITE_DISK_BYTE_D ; byte written is returned in A
RAM:666C 10 FB djnz loc_6669 ; Write $FF 127 times
RAM:666E 16 D5 ld d, 0D5h
RAM:6670 CD 64 78 call WRITE_DISK_BYTE_D ; byte written is returned in A
RAM:6673 D3 11 out (11h), a ; turn off self-sync
RAM:6675 16 AA ld d, 0AAh
RAM:6677 CD 64 78 call WRITE_DISK_BYTE_D ; byte written is returned in A
RAM:667A 16 96 ld d, 96h
RAM:667C CD 64 78 call WRITE_DISK_BYTE_D ; byte written is returned in A
RAM:667F FD 56 7C ld d, (iy+7Ch)
RAM:6682 42 ld b, d ; 1st byte is VOLUME #
RAM:6683 CD 6D 78 call WRITE_4X4_D ; write 4x4 track/sector header ID bytes
RAM:6686 FD 7E 7F ld a, (iy+7Fh)
RAM:6689 57 ld d, a ; Second Byte is TRACK #
RAM:668A A8 xor b
.......
Edited by RedskullDC
  • Like 1

Share this post


Link to post
Share on other sites

Just looking at the differences between DOS1.0 and DOS1.1.

 

One thing that immediately stands out is that DOS 1.1 supports formatting double sided floppys.

 

Init command followed by a 'D' will format a disk as double sided if a double sided drive is attached.

 

Cheers,

Leslie

 

DOS 1.1 INIT code:

 

 

RAM:661E INIT: ; CODE XREF: RAM:5F12↑j
RAM:661E ; DATA XREF: RAM:63CA↑o
RAM:661E CD ED 69 call GET_DRIVESPEC
RAM:6621 CD F4 69 call CHECK_DOUBLE_SIDED
RAM:6624 E5 push hl
RAM:6625 FD CB 43 BE res 7, (iy+43h) ; Select Side #0
RAM:6629 CD 8F 66 call FORMAT_DISK ; format side #0
RAM:662C B7 or a
RAM:662D C2 06 62 jp nz, dos_error
RAM:6630 3A 40 FB ld a, (DOUBLE_SIDED)
RAM:6633 B7 or a
RAM:6634 28 0B jr z, loc_6641
RAM:6636 FD CB 43 FE set 7, (iy+43h) ; select side #1
RAM:663A CD 8F 66 call FORMAT_DISK ; format side #1
RAM:663D B7 or a
RAM:663E C2 06 62 jp nz, dos_error
...
RAM:69F4 CHECK_DOUBLE_SIDED: ; CODE XREF: RAM:6621↑p
RAM:69F4 ; RAM:loc_6C62↓p
RAM:69F4 E5 push hl
RAM:69F5 CD E2 69 call sub_69E2
RAM:69F8 FE 44 cp 44h ; 'D' ; 'D' on command line to specify double sided
RAM:69FA 20 0C jr nz, single_sided
RAM:69FC CD E2 69 call sub_69E2
RAM:69FF 20 07 jr nz, single_sided
RAM:6A01 3E AA ld a, 0AAh
RAM:6A03 32 40 FB ld (DOUBLE_SIDED), a
RAM:6A06 F1 pop af
RAM:6A07 C9 ret
RAM:6A08 ; ---------------------------------------------------------------------------
RAM:6A08
RAM:6A08 single_sided: ; CODE XREF: CHECK_DOUBLE_SIDED+6↑j
RAM:6A08 ; CHECK_DOUBLE_SIDED+B↑j
RAM:6A08 E1 pop hl
RAM:6A09 AF xor a
RAM:6A0A 32 40 FB ld (DOUBLE_SIDED), a
RAM:6A0D C9 ret
  • Like 2

Share this post


Link to post
Share on other sites

Hi Leslie, nice to read you here!

Regarding the 8/16 bit flag, I don't have understood well how it should work (thinking how I should modify the emulator), can you make an example?

BTW disk images in the emulator can be saved and inspected (they are encoded of course). Use
save("myimage.dsk") and then download("myimage.dsk") from the JavaScript console (F12).

If you inspect a disk image you'll notice that sectors are stuffed close one other on each track because rotation speed is not emulated (yet).

Regarding the double sided disk, nice find! but I can't figure how to issue the "INIT D" command. I tried INIT D and INIT "D" but they are all syntax errors.

Share this post


Link to post
Share on other sites

Hi Nippur,

 

Regarding the 8/16 bit flag, I don't have understood well how it should work (thinking how I should modify the emulator), can you make an example?

BTW disk images in the emulator can be saved and inspected (they are encoded of course). Use
save("myimage.dsk") and then download("myimage.dsk") from the JavaScript console (F12).

Regarding the double sided disk, nice find! but I can't figure how to issue the "INIT D" command. I tried INIT D and INIT "D" but they are all syntax errors.

 

Thanks for the welcome :)

 

There isn't any need to emulate the "8/16" latch on your emulator.

The byte values will always be correctly synchronised when working with disk images.

 

The "self-sync" bytes are important on a *real* disk drive to allow the disk controller to get itself in sequence with the start of each byte.

 

Example Disk stream:

 

Sector header, 5 $FF self-sync bytes, Sector data, trailer, more $FF self-sync bytes.... next Sector Header.

 

D5 AA 96 <VOL> <TRK> <SEC> <CHK> DE AA EB FF FF FF FF FF D5 AA AD <342 bytes of 6+2 encoded data> <CHK> DE AA EB FF FF FF FF ....

 

The $FF self-sync bytes are actually 10 bits long, with two trailing ZEROS:

 

11111111001111111100111111110011111111001111111100 then <D5> 11010101 .....

 

The sector data area can be re-written.

That means the area between DE AA EB and D5 AA AD can be overwritten multiple times, causing that area to be inconsistent.

 

The 5 x $FF self-sync bytes *guarantee* that by the time the controller reaches the "D5" byte in the D5 AA AD sector data area,

it will be correctly synced up bytewise.

Doesn't matter where the controller starts reading in the byte stream, after 5 $FF self-sync bytes, it will be correct.

 

Code from the 1.1 Format Disk routine that turns self-sync mode on and off:

 

RAM:6701 16 EB ld d, 0EBh
RAM:6703 CD 11 79 call WRITE_DISK_BYTE_D
RAM:6706 06 04 ld b, 4
RAM:6708 16 FF ld d, 0FFh
RAM:670A CD 11 79 call WRITE_DISK_BYTE_D
RAM:670D D3 11 out (11h), a ; self-sync *on*
RAM:670F
RAM:670F loc_670F: ; CODE XREF: FORMAT_DISK+83↓j
RAM:670F CD 11 79 call WRITE_DISK_BYTE_D
RAM:6712 10 FB djnz loc_670F
RAM:6714 16 D5 ld d, 0D5h
RAM:6716 CD 11 79 call WRITE_DISK_BYTE_D
RAM:6719 D3 11 out (11h), a ; self-sync *off*
RAM:671B 16 AA ld d, 0AAh
RAM:671D CD 11 79 call WRITE_DISK_BYTE_D
RAM:6720 16 AD ld d, 0ADh
---------------
For double sided formatting:
Select the drive you want to use with "DRIVE 1" or "DRIVE 2".
Then try "INIT:D"
It may give some odd results on your emulator, as there isn't any code to handle the side-select bit yet?
Regards,
Leslie
Edited by RedskullDC

Share this post


Link to post
Share on other sites

Leslie,

great, the INIT:D command and that produces a 308 K free space disk, but of course the extra head needs to be handled in the emulator (gonna fix it soon)

Regarding the 8/16 bit flag, what I have understood so far is:

- the 5 x FF sequence is used as an in-track sector separator, as it's a sequence that never occurs in the data (thanks to the encoding)
- when the 8/16 flag is turned on, the controller writes bytes with two extra "00"
- when DOS 1.1 formats a disk, it turns on the 8/16 flag only for the FF sync sequence

What's still unclear is:

- what is the purpose/usefulness of the two extra bits?
- what happens when you read a DOS1.1 formatted disk, who handles/discards the extra "00" ? Is it the controller or the DOS ?

- does the WRITE_SECTOR routine write also the FF sequence at the end of the sector? Or does it write just the data block?


Share this post


Link to post
Share on other sites

Hi Nippur72,

 

Leslie,

What's still unclear is:

- what is the purpose/usefulness of the two extra bits?
- what happens when you read a DOS1.1 formatted disk, who handles/discards the extra "00" ? Is it the controller or the DOS ?

- does the WRITE_SECTOR routine write also the FF sequence at the end of the sector? Or does it write just the data block?

 

The GCR encoding employed by the Laser controller requires that all bytes read have the high bit set.

No matter where the controller begins reading, after encountering 5 of these $FF self-sync bytes, the next byte

read will be guaranteed to be lined up so that the very next byte following the $FF sequence will be correctly

aligned , with the read head positioned to read bit 7 of the following byte.

 

DOS never sees the extra two bits, they are just for synchronising the controller with the start of the next data byte.

 

This page in the Beneath Apple Dos book may help to visually explain how the self-sync bytes work:

https://archive.org/details/Beneath_Apple_DOS/page/n9

 

The WRITE_SECTOR routine locates the required sector header.

It then switches the write request signal *on*

Then writes five self-sync $FF bytes.

followed by the D5 AA AD ID bytes before it writes the 342 data bytes, checksum, and DE AA EB trailer bytes.

 

It does not write any self-sync bytes after the data block itself.

 

However, the disk format routine *does* insert self-sync bytes between the DE AA EB trailer bytes, and the following sector header.

 

I'll post a full disassembly in the next few days :)

 

Regards,

Leslie

 

P.S. The track numbers used for the second side of the drive appear to be 40-79, but the track ordering seems reversed.

By that I mean track 40 is in the middle of the disk, and track 79 is on the outer edge of the disk:

 

 

RAM:79B7 ; read/write sector data. B=1 for READ, B=0 for WRITE
RAM:79B7
RAM:79B7 READ_WRITE_SEC_DATA: ; CODE XREF: RAM:5F21↑j
RAM:79B7 ; sub_644B+36↑p ...
RAM:79B7 21 43 FB ld hl, CURRENT_DRIVE
RAM:79BA FD 7E 0B ld a, (iy+0Bh) ; examine drive mask
RAM:79BD FE 40 cp 40h ; '@'
RAM:79BF FD 7E 43 ld a, (iy+43h) ; get current LATCH value
RAM:79C2 20 06 jr nz, loc_79CA
RAM:79C4 CB AF res 5, a ; drive#1
RAM:79C6 36 01 ld (hl), 1 ; also save in CURRENT_DRIVE
RAM:79C8 18 04 jr loc_79CE
RAM:79CA ; ---------------------------------------------------------------------------
RAM:79CA
RAM:79CA loc_79CA: ; CODE XREF: READ_WRITE_SEC_DATA+B↑j
RAM:79CA CB EF set 5, a ; drive#2
RAM:79CC 36 02 ld (hl), 2
RAM:79CE
RAM:79CE loc_79CE: ; CODE XREF: READ_WRITE_SEC_DATA+11↑j
RAM:79CE FD 77 43 ld (iy+43h), a ; save current LATCH value
RAM:79D1 FD 7E 12 ld a, (iy+12h) ; Look at Track#
RAM:79D4 FD CB 43 BE res 7, (iy+43h)
RAM:79D8 FE 28 cp 40 ; Track 40+ denotes second side of the disk?
RAM:79DA 38 08 jr c, side_zero
RAM:79DC FD CB 43 FE set 7, (iy+43h) ; Set side#2 in the status register
RAM:79E0 D6 4F sub 79 ; normalise the Track#
RAM:79E2 ED 44 neg ; track numbers on side#2 are reversed? 40 = innermost, 79 = outer.
RAM:79E4
RAM:79E4 side_zero: ; CODE XREF: READ_WRITE_SEC_DATA+23↑j
RAM:79E4 32 42 FB ld (REQUIRED_TRACK), a
RAM:79E7 FD 5E 11 ld e, (iy+11h) ; get sector#
R

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...