Jump to content
IGNORED

Any info on Video Technology Laser 500 computer?


31336haxx0r

Recommended Posts

We should start keeping a library of all L500 software :-)

 

BTW, we are working on adding the Laser 500 as target platform for the z88dk C compiler. Follow the discussion on github: https://github.com/z88dk/z88dk/issues/854

 

@CatPix does the manual contains something about the I/O (speaker/cassette/keyboard) ? In case would you please post a pic of the page?

  • Like 1
Link to comment
Share on other sites

I figured out how to read and write from and to I/O.

 

As an example, here is the small program "TAPE MONITOR".

 

https://drive.google.com/open?id=1nH2cIKtqjCdm_TB6SYQ54ZYsYCQC9HLU

 

It reads the cassette bit and changes the screen color accordingly.

 

To run it, go in TEXT 80, enter MON, R, and then start with 9000G

 

What it does:

 

9000,01 switches to bank 2 (I/O) in memory slot 2 (port 41h)

9002 reads the bit 7 of cell 6800h, where the I/O is mapped. Bit 7 is tape.

9009,B writes in port 44h as border color; bit 1 is set to preserve TEXT 80

900D sets as background color by writing to port 45h after adjusting the value

9017 repeats

 

 

 

 

post-31739-0-49802100-1535820476_thumb.jpg

Edited by nippur72
  • Like 1
Link to comment
Share on other sites

On the Laser 500, the 8 64Kb DRAM chips are shared between the CPU and the video hardware. The CPU accesses RAM through the VLSI IC, which acts as a proxy and can insert wait states for the CPU if the RAM is already in use by the video hardware.

 

this is interesting in view of an accurate emulation. So if I've get it correctly, when the CPU tries to read or write in the 16K video address space it is put on hold until the video chip has finished drawing. What is the granularity of such operation? Is it at the raster level or on the whole page? I mean, when the CPU is waiting, does it resume when the "beam" reaches the start of the right border? Or does it resume only when the last scan line is drawn?

Link to comment
Share on other sites

regarding the contended memory between CPU and VDC, I ran a small experiment: a loop writing "A" into the first screen cell and then alternating screen colour at each iteration (see the attached pic).

 

Since there is no significant difference between background and border, I deduce the impact of memory contending in Laser 500 is minimal or non-existent.

 

The same loop, but writing outside of the video memory didn't change anything.

 

Do you have any theories how they made it?

 

BTW, there is nice wikipedia article on ZX_Spectrum_Contended_Memory:

 

https://en.wikipedia.org/wiki/ZX_Spectrum_Contended_Memory

post-31739-0-19153600-1535995785_thumb.jpg

  • Like 1
Link to comment
Share on other sites

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:

The CPU clock (CPUCK) is shown in the diagram as a series of rectangular pulses at 3.7 MHz with a 50% duty cycle.

CV is a signal used in the VLSI to split the synchronization system in VIDEO and CPU cycles. When CV = 1, RAM access will be a VIDEO access, and a CPU access otherwise.

The /RAS, /CAS and /AX signals in the DRAM subsystem are shown as rectangular pulses at the same frequency as the CPU. Their timings are defined to comply with CPU/VIDEO and DRAM requirements.

A specific technique is used in the VLSI to synchronize the CPU and the multiplexed RAM. When a memory access occurs, such as an opcode fetch, or data read or write, the CPU brings the /MREQ line to a logical 0. It notifies the VLSI that a memory transaction will take place. The VLSI acknowledges by bringing the /WAIT line to a logical 0, adding a wait cycle to every CPU memory operation. That WAIT signal will last a CPU cycle before returning to a high logical level, releasing the CPU for the next operation.

Adding that wait cycle guarantees that CPU data is read during the appropriate CV phase, and that CPU data is written in the CPU phase of CV. The internal VLSI circuitry ensure that the data is latched at the appropriate time.

Do you have any theories how they made it?

Hopefully that should answer your question :)

post-63190-0-50630300-1536100034_thumb.jpeg

post-63190-0-24984200-1536100044_thumb.jpeg

Edited by Bonstra
  • Like 1
Link to comment
Share on other sites

fantastic, thanks a lot !

As I'm going to write an emulator (because MESS is just a mess) I will have to take into account this design (though I'm not sure I will emulate it at the cycle level).

The tape schematic is also very interesting, we are just dealing with it in the z88dk compiler, and also it's useful to fix the loading bug in MESS.

 

Thank you again!

Link to comment
Share on other sites

@Bonstra if possible, can you please post any info regarding the keyboard ? I'm having troubles understanding how it works precisely. Intuitively it should be like in Laser200, e.g. keys mapped in I/O space, columns on the data bus (6 bits) and rows in the address bus (11 bits), with negative logic ("0" means key pressed). But I'm unable to read keys from row > 9 for some reason. Perhaps it's the same reason why they don't get them right in MESS emulator too (and hopefully we can fix that).

BTW, talking of emulators, here is my work in progress: https://nippur72.github.io/laser500emu

  • Like 1
Link to comment
Share on other sites

While playing with my emulator I just discovered about the "neglected page 6"!

The docs say there are pages from 4 to 7, where 4 and 5 are the 32 K free for the basic, and 7 is the video memory. But what about the 6?

Well it's there and it's almost unused. In basic, its only purpose is to store KEY definitions. Type the following:

10 a$=string$(255,"X")
20 print fre(0)
30 for t=1 to 30
40 key t,a$
50 next
60 print fre(0);input$(1)
70 key list

See how the memory is always ~29K ?

Link to comment
Share on other sites

Joystick ports? Are those accessed through the expansion port? I know the VTech Laser 2001 has more or less Atari compatible joysticks, but I never spotted any DE9 connectors on my VTech Laser 500.

 

Or well, I see there are cut-outs on the inside of the plastic for joysticks, but at least on this one it doesn't seem to lead anywhere. Is that a feature of the 700 and 750 models?

http://www.nightfallcrew.com/05/03/2017/video-technology-vtech-laser-500-color-computer/

 

OTOH this Spanish entry for the 700 has an image of the JS20 joysticks with interface.

https://es.wikipedia.org/wiki/VTech_Laser_700

Edited by carlsson
Link to comment
Share on other sites

@Bonstra if possible, can you please post any info regarding the keyboard ? I'm having troubles understanding how it works precisely. Intuitively it should be like in Laser200, e.g. keys mapped in I/O space, columns on the data bus (6 bits) and rows in the address bus (11 bits), with negative logic ("0" means key pressed). But I'm unable to read keys from row > 9 for some reason. Perhaps it's the same reason why they don't get them right in MESS emulator too (and hopefully we can fix that).

 

BTW, talking of emulators, here is my work in progress: https://nippur72.github.io/laser500emu

Good job for the emulator icon_thumbsup.gif

 

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
Link to comment
Share on other sites

@carlsson, yes the joysticks were the JS20 in the picture, they attached to the expansion slot (not memory expansion). If I remember well it is the same port we attached the printer, the plotter and the light pen. I think it is connected directly to the I/O ports of the Z80.

@Bonstra ok for the keyboard, thanks, I got it working now... it was the most difficult part. It responds only to 6800-6fff (when mapped in bank 2) not to just any address in the 16K space. I also believe they added the extra lines when they decided to move from 350 to 500. Indeed the 350 is a 500 in a 310 case which does not have "extended" keys. The ROM is able to detect which machine is running depending on the availability of bank 3. If bank 3 is found then Laser 350 is assumed and the "KEY n" basic command is disabled.

The emulator is almost finished, I only have to fix minor details (exact timings etc). It's very handy when doing cross development, it's much more quick and accurate than MAME.

  • Like 1
Link to comment
Share on other sites

Trying to emulate as accurate as possible, I noticed there is a little "snow" effect when you switch the video to the missing page 3 (available only on L350). That happens only when keys on the keyboard are pressed. Do you have any explanation why this happens?

 

Of course switching to page 3 it's of no use since the screen goes all white due to 0xFF being constantly read on the data bus. It's just a curiosity.

 

Try it yourself:

OUT &H44, 8
Link to comment
Share on other sites

In order to get precise timings for my emulator, I hooked the interrupt vector and used the raster line as a reference. The idea was to change the screen colors, perform delay loops see where the raster is tracing. I did that first on the real hardware and then on the emulator, adjusting the timings accordingly.

 

In the process I've discovered a number of interesting things:

- there are 576 visible scanlines plus 24 hidden, for a total of 625 lines (standard PAL)

- each scanline is repeated twice, thus halving the vertical resolution

- the CPU NMI interrupt is generated at the end of the 576th line, not at 625 as I believed (this is good because that gives extra CPU time for videogames)

- the visible text area (24 character rows) is not centered vertically, it is one row up (5 chars above, 7 chars below).

- the Z80 cpu executes 190 clock cycles per scanline

 

Now here is where my calculations do fail: 190 cycles x (576/2) x 50 Hz = 2736000 = ~ 2.7 Mhz which is much below the 3.6 Mhz of the theoretical CPU speed. Where is the missing Megahertz?

 

And I am pretty sure of the timings because the emulator speed matches precisely the real hardware. Perhaps it's the time spent fetching/decoding the instruction? Or am I missing something else?

In the picture below, I change color to yellow at the start of the NMI interrupt, then wait a bit and change to red/gray. This is how I measured the time elapsed in drawing the screen. On a separate measure I tried to wait to the last scanlines to assess where the frame ends. Since the CPU is locked in the delay, the cursor became very laggy and unresponsive. Waiting too much caused the interrupt routine to skip a beat and show flashing colors.

 

post-31739-0-82530000-1536785538.jpg

  • Like 1
Link to comment
Share on other sites

In order to get precise timings for my emulator, I hooked the interrupt vector and used the raster line as a reference. The idea was to change the screen colors, perform delay loops see where the raster is tracing. I did that first on the real hardware and then on the emulator, adjusting the timings accordingly.

 

In the process I've discovered a number of interesting things:

- there are 576 visible scanlines plus 24 hidden, for a total of 625 lines (standard PAL)

- each scanline is repeated twice, thus halving the vertical resolution

- the CPU NMI interrupt is generated at the end of the 576th line, not at 625 as I believed (this is good because that gives extra CPU time for videogames)

- the visible text area (24 character rows) is not centered vertically, it is one row up (5 chars above, 7 chars below).

- the Z80 cpu executes 190 clock cycles per scanline

 

Now here is where my calculations do fail: 190 cycles x (576/2) x 50 Hz = 2736000 = ~ 2.7 Mhz which is much below the 3.6 Mhz of the theoretical CPU speed. Where is the missing Megahertz?

 

 

Vertical and horizontal retrace time?

 

https://en.wikipedia.org/wiki/Vertical_blanking_interval

Edited by Platis
Link to comment
Share on other sites

 

Trying to emulate as accurate as possible, I noticed there is a little "snow" effect when you switch the video to the missing page 3 (available only on L350). That happens only when keys on the keyboard are pressed. Do you have any explanation why this happens?

 

Of course switching to page 3 it's of no use since the screen goes all white due to 0xFF being constantly read on the data bus. It's just a curiosity.

 

Try it yourself:

OUT &H44, 8

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.

  • Like 1
Link to comment
Share on other sites

another little discovery: from a picture of a Laser 770 (link below) it can be seen that such machine has no expansion slot; in its place there are the two disk drive connectors. The missing expansion slot means it cannot load external ROMs implying the DOS ROM must be onboard.

 

So the ROM labeled "VTL 27-0401-00-00 // 6133-7081 // 8611MAK" in MESS/MAME is wrong, the label is from Laser 700 but the dumped content is from Laser 350/500.

 

https://www.flickr.com/photos/12426986@N03/7615777038/

  • Like 2
Link to comment
Share on other sites

another little discovery: from a picture of a Laser 770 (link below) it can be seen that such machine has no expansion slot; in its place there are the two disk drive connectors. The missing expansion slot means it cannot load external ROMs implying the DOS ROM must be onboard.

 

So the ROM labeled "VTL 27-0401-00-00 // 6133-7081 // 8611MAK" in MESS/MAME is wrong, the label is from Laser 700 but the dumped content is from Laser 350/500.

 

https://www.flickr.com/photos/12426986@N03/7615777038/

 

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

post-63190-0-17925700-1537045960_thumb.jpeg

Edited by Bonstra
Link to comment
Share on other sites

THE RESET KEY IN LASER 500

The reset key is not like any other key in Laser 500, instead of being part of the keyboard matrix, it is directly connected to the CPU reset pin (hence the name "reset").

That's why the key is able to bring the user back to the "Ready" prompt in almost any situation. It gets out of any loop the CPU is stucked by simply resetting it.

Resetting the Z80 means the CPU clears all its internal registers and begins to execute instructions from location $0000 (in the ROM address space). That's what happens also when you turn on the computer.

But yet pressing the "reset" key does not initializes the machine, the BASIC program is not erased, only the prompt is brought back. How is that?

The ROM kernel has a trick for knowing whether it's a warm boot or a cold one.

When initializing, it checks the 16-bit pointer contained in RAM at $861D, which should contain the "warm reset" routine. If the bytes from this pointer added together plus the constant $E1 matches the content of $861F then it's warm reset, and the CPU continues just from $861D.

Otherwise, it's assumed the bytes in the pointer are just uninitialized RAM random values and thus it's a "cold" start. The constant $E1 is added in the sum to avoid zero values of a uninitialized RAM give a false match.

Part of the "cold" start involves writing the right values in the $861D pointer and $861F check byte, so that any successive
reset will be a "warm" one.

Normally the pointer is initialized with the value $66C8 which is the actual warm reset routine in the ROM.

To see that:

MON
<MON>
861D,861FM
861D: C8 ; $66C8 points to warm reset in ROM
861E: 66 ;
861F: 11 ; calulated as: $66+$C8+$E1=$11 (low byte only)

change any of these, press "reset" and the machine will do a cold start.

 

  • Like 1
Link to comment
Share on other sites

Also the VTech Laser 3000 (a.k.a. Dick Smith CAT) is quite Apple alike. Even the Laser 2001 is said to share a few characteristics with the Apple, or at least its BASIC.

 

It's a bit interesting if the Laser 1xx/2xx/300 are more or less colour variants of the original TRS-80, but that VTech slowly moved into Apple land, and the 350/500/700 would be Z80 designs inspired by Apple.

Edited by carlsson
  • Like 1
Link to comment
Share on other sites

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" icon_wink.gif

  • Like 1
Link to comment
Share on other sites

I don't know the Apple, but that would not surprise me considering that at some point VTech cloned it making the Laser 128.

P.S. for those who are into Facebook, we have a Laser500/700 dedicated group: https://www.facebook.com/groups/263150584310074/

The Reset vector on the Apple ][+ works like this: the address is stored at 0x03F2, and a check byte at 0x03F4 which is the high byte XOR'd with 0xA5. If the byte at 03F4 matches the byte at 03F3 XOR'd with A5, it will jump to the address stored at 03F2 instead of doing a full reset.

 

Not very different from what was described of the Laser 500.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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