Bonstra

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

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

Those are great news! Congrats! 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.

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

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

Nicely done! Well, disk 3 even have a DOS BASIC 1.1 Indeed, fix applied!

I'm already working on it. If you want to emulate the FDC, you should know that: - there is some uncertainty about the I/O registers: I don't know what the 16 bit mode does, I'm not sure about the write sense bit polarity, and I don't know what signals are valid when no drive is selected. - the .DSK image format is a very simple and high-level one (all the sectors data, already decoded, is concatenated). The Laser FDC however, just like the Apple II disk controller, works at a lower level, and the software has to do all the work of reading sector address fields and decoding data. - you will need to emulate the disk at the "bit cell" level. I recommend this book which describes the disk format with more details than I did (only the disk format is relevant, with the difference that Laser disks have up to 40 tracks).

I added the information I have about the floppy disk controller/drive here. I only have very basic info about the FDC I/O interface, but now that we have a DOS image, we can disassemble it to get more info, especially how to write data to the disk. The track format on the disk is the same as the one used by Apple DOS 3.3. The hardware works pretty much the same way, except the Laser 700 uses 40-track disks (vs. 35 for Apple DOS), and the FDC does not have an embedded ROM. You could try to plug both drives to the Laser 700, the 5"1/4 on port 1 and the 3" on port 2. The ROM only tries to boot from drive 1. I do not have any documentation about the DOS commands, but the full list is: LOAD, SAVE, OPEN, CLOSE, BSAVE, BLOAD, BRUN, DIR, ERA, REN, INIT, DRIVE, IN#, PR#, DCOPY, STATUS, WRITE, ACCEPT, PUT and GET. To be safe, remove the DOS system disk from the drive while testing those commands! You could try "DRIVE 2" to select the 3" drive, and then "INIT" to format it. If that works, you can then swap the drives (after powering the Laser 700 off, of course ) and try booting from the 3" disk you just formatted to see whether the system was actually transferred to it. The DCOPY command also looks interesting, but I would not experiment with it unless I already have at least 2 copies of the DOS system disk

That's a really pleasant surprise Thank you! Did you use the Laser FD-100 to dump the disks? Do you know whether the FD-100 have 1 or 2 heads? According to the pinouts in the manual, pin 9 is SIDESEL (instead of -12V on the Apple Disk II). I'm curious to know whether the Laser FD-100 actually uses this signal. Having at least one valid disk image, it should be enough to be able to generate a simulated magnetic flux, and test it by letting the BASIC ROM boot the DOS from the emulated floppy.

I put some info from the manual, as well as the result of some research I did about the DRAM chips, in a git repository: https://github.com/Bonstra/laser500-doc I'll add more info when I have time. I have started disassembling the ROM routines that make use of the FDC. The ROM has minimal support to boot from a floppy, but that should be enough to understand (part of) the disk format. The FDC appears to be a custom (but simple) design, burnt to a gate array chip manufactured by Toshiba. The FDC emulated by MAME appears to be similar in its design, but the registers are laid out differently. I'll write a very basic emulation of the FDC interface in nippur72's emulator and try to make a "hello world" disk image which is sufficiently well-formed to be booted by the ROM. Unfortunately, I lack the actual hardware or disk images to ensure emulation is accurate, but that's a start. BTW, if you're looking for datasheets for old ICs, this FTP site is a gold mine: ftp://bitsavers.informatik.uni-stuttgart.de/ Look for "_dataBooks" in "components"

On the picture you linked, the only ROM ICs are: the 32KB BASIC ROM (VTL 27-0401-00-00) the 8 KB character generator ROM (27-393-00) The board of my Laser 500 has exactly the same ROM ICs as that Laser 700. The identifiers are the same, so their content must be identical. Also, given how packed the Laser 500 BASIC ROM is to fit into 32KB, I don't think VTL could have added anything without removing other features. The Laser 700 is basically the high-end version of the Laser 500, with all the useful extensions built-in (64KB memory expansion, disk drive interface, Centronics interface). Using the same components, hardware and software, for both the 350, 500 and 700 reduces production costs while making it easy to write software compatible for all versions. Early Laser 500/700 units were using 2x 16KB EPROMs to store the BASIC ROM, later models use a single 32KB mask ROM to reduce costs. You can see the unpopulated space on the PCB for the second ROM chip and the 74Lxxx chip used for the address decoding logic. The 8KB chargen ROM was also replaced by a mask ROM manufactured by TI. I attached a picture of the PCB of my Laser 500 so you can see the changes from the early Laser 500 unit in that picture https://www.flickr.com/photos/grupousuariosamstrad/7615785522/ (I also discovered that the memory expansion port is actually an internal port, the one marked "J3") About the BASIC DOS extensions, a possibility is that they could be loaded from disk on boot. That's what Thomson did with their BASIC DOS extensions for the TO7 (they also had a separate manual documenting the DOS commands). P.S. the manual also mentions that there exist 64KB and 128KB RAM variants of the Laser 700

My guess is that the VLSI is acting as a bus keeper, holding the last logic level seen on the DRAM data bus. Since there is no DRAM chip for bank 3, the value read by the VLSI during its video cycle is the last value accessed to/from an existing location in DRAM. I think the reason you see changes on the screen when you press a key is because the CPU still executes the VBLANK ISR, and scans the keyboard, storing some values in DRAM. That must not be the only reason though, since disabling the interrupts and jumping to a HALT instruction in ROM results in a perfectly blank screen, but doing the same running the HALT instruction from RAM still causes some noise to appear.

Good job for the emulator About the keyboard, on the Laser 500, the keyboard matrix is composed of 7 columns and 12 rows. When a key is pressed, is create a physical contact between the the column trace and the row trace the key is sitting on. To check which keys are pressed on a row, you need to first select the row you want to read and check the logical level of each column. A low level means the key at (row, column) is pressed. Reading from bank 2 (memory mapped I/O) will enable the output buffer connecting the 7 keyboard column lines and the cassette input line to the data bus. The byte the CPU will read will have the value of the 7 columns in bits 0-6, and the cassette input level in bit 7. The 11 least significant bits of the address where you perform the read operation are used to select which row is "enabled" on the keyboard matrix. The selected row must be the only one at level 0. For rows 0 through 7, there is a 1:1 mapping between the bits in the address and the rows lines: 0x_7fe will read row 0, 0x_7fd will read row 1, etc, until row 7 (0x_77f) For rows 8 through 10, however it works differently. I assume they added keys and ran out of address lines to tie to the keyboard matrix, so they added a multiplexer (74LS138) to be able to choose between 4 rows (or none) using only 3 address bits. The multiplexer selects a single row depending on address bits 8-10: 0 -> row 8 1 -> row 9 2 -> row 10 3 -> row 11 4-7 -> not connected To sum up: Address[0:10] Row 0x7fe 0 0x7fd 1 0x7fb 2 0x7f7 3 0x7ef 4 0x7df 5 0x7bf 6 0x77f 7 0x0ff 8 0x1ff 9 0x2ff 10 0x3ff 11

I took some time to digitize the manual pages describing the cassette signals and the CPU/Video memory access timing diagram. Here's my attempt to translate the text from the page next to the timing diagram: Hopefully that should answer your question

Banks C through F are for expansion ROM, made available through the expansion connector. At startup, the BASIC ROM will look for a magic value (byte sequence AA, 55, E7, 18) in banks 2, C, D, E and F (in that order), and transfer execution to that ROM bank at offset 0x0004 if such a value is found (the bank gets mapped at 0000-3FFF in Z80 address space). The manual mentions that the BASIC ROM can detect the presence of the disk unit interface by writing the I/O port 0x13 and reading back the result (this is the data buffer, so if the disk interface is present, you should read back the same value you've written). And if the disk interface is present, the sector 0 of track 0, will be loaded to memory location 0xA200, and execution will resume at that location (after checking that the boot signature is there, I assume). So it appears there is a least minimal support for the disk drive interface in the BASIC ROM, but it doesn't exclude loading a fuller support from an expansion ROM module. It must be the character generator ROM, used by the VLSI to draw the characters to screen in text mode. IIRC, MAME knows only one chargen ROM, but there are actually regional variations (accented characters for France, pound sign for the UK, …). As for the warning, a comment in the code says that the ROM was dumped using the wrong size: only 2KB were dumped, while the 2764 is a 8KB EPROM, hence the warning. I don't think it matters much for the usual text mode emulation purposes, but MAME maintainers are thorough people, and since all the address lines are connected to the VLSI, the other 6KB must be used for something, right?