Jump to content
31336haxx0r

Any info on Video Technology Laser 500 computer?

Recommended Posts

Leslie one more question: what's the /AX signal on the diagram? /RAS and /CAS I understand are the row and col memory address select (btw I guess such signals are generated by the VLSI, right?).

Share this post


Link to post
Share on other sites

 

Leslie one more question: what's the /AX signal on the diagram? /RAS and /CAS I understand are the row and col memory address select (btw I guess such signals are generated by the VLSI, right?).

 

 

 

Nothing you need to worry about from an FPGA point of view.

 

AX = Address multipleX.

 

Between the Z80 and GA1 on the schematic are 2 x 74LS257 Multiplexers.

 

AX is connected to the Select line on both of those chips, and is used to multiplex the A15-A0 address bus down to the MA7-MA0 signals which go to the DRAMs

 

Sequence is:

 

1. At the start of a video/cpu "slot", *RAS, *AX, *CAS are all high.

2. Multiplexers are currently selectin the "ROW" address bits

3. *RAS goes low, registering the ROW bits in the DRAMS

4. AX changes state, Multiplexers are now selecting the "COLUMN" address bits

5. *CAS goes low, registering the COLUMN bits in the DRAMS

6. DRAMs now have the full address information.

 

----

 

The address multiplexers only appear to be used for when the Z80 is addressing the DRAMs.

 

GA1 has its' own MA7-MA0 outputs for when the video section is addressing the DRAMs

 

The CVAM output from GA1 (CPU/VIDEO-ADDRESS-MULTIPLEX?) can disable the multiplexer outputs.

That will be the CV signal shown in the timing diagram.

 

-----

 

Interesting to see the selection of ROW bits are A0, A1, A2, A3, A4, A8, A9, A10.

 

This means that the 7 bit refresh address generated by the Z80 is ignored completely.

 

VIDEO section multiplexers inside GA1 must be similarly wired as the external CPU ones.

I haven't checked, but I wouldn't mind betting those particular address lines cycle through all 256 combinations as a result of the screen being re-drawn,

no matter what screen mode is being displayed.

 

In effect, providing an invisible 8 bit DRAM refresh cycle ;-)

 

Regards,

Leslie

Share this post


Link to post
Share on other sites

Leslie, what is the access time of those DRAMs in the Laser 500? I have the video chip running at 14 Mhz, can I assume that I can read the DRAMs in one 14Mhz cycle? Or two, three ... ?

Share this post


Link to post
Share on other sites

I was looking at the 700 and 500 mainboard pictures that are online:

- the VLSI chip is labeled differently ("VTL 0390-00-00"): on the L700 it's "MD61800", on the L500 it's "MD52701". I guess it's the revision number?

- on the 700 you can see the two XTALs (17 and 14 Mhz as from the schematic), but in the 500 there is only one...! (see picture attached) How is that possible?

Also on the schematic there is the "F3M" pin on the leftmost side of the F14M circuit. Is that an input or output? I can't find F3M elsewhere on the schematics, it just goes directly into the VLSI chip. Any guesses?

post-31739-0-66789800-1556885242_thumb.jpg

Edited by nippur72

Share this post


Link to post
Share on other sites

Leslie, what is the access time of those DRAMs in the Laser 500? I have the video chip running at 14 Mhz, can I assume that I can read the DRAMs in one 14Mhz cycle? Or two, three ... ?

 

4 x 14MHz cycles.

 

My Laser 500 hasn't arrived yet.

 

The video and cpu "slots" are both 1 CPU clock wide (3.6947MHz) or 4 x 14.77873MHz clocks wide.

 

Period of one CPU clock at 3.6947MHz is approximately 271ns long.

 

A pic of the 500 motherboard:

https://www.flickr.com/photos/grupousuariosamstrad/7615785522

 

shows it to be fitted with 150ns DRAM chips.

 

DRAMs are easily able to responding within the 271ns "slot" .

 

Regards,

Leslie

Share this post


Link to post
Share on other sites

I was looking at the 700 and 500 mainboard pictures that are online:

 

- the VLSI chip is labeled differently ("VTL 0390-00-00"): on the L700 it's "MD61800", on the L500 it's "MD52701". I guess it's the revision number?

 

- on the 700 you can see the two XTALs (17 and 14 Mhz as from the schematic), but in the 500 there is only one...! (see picture attached) How is that possible?

 

Also on the schematic there is the "F3M" pin on the leftmost side of the F14M circuit. Is that an input or output? I can't find F3M elsewhere on the schematics, it just goes directly into the VLSI chip. Any guesses?

 

 

 

VLSI chips differences are probably just batch numbers.

Not sure there would be any revision differences.

 

17MHz crystal may only be required for the CHROMA and COLOURBURST signals?

I've seen a couple of 500's with no RF modulator fitted.

 

 

Not really sure of the purpose of the F3M pin on the VLSI chip.

Perhaps they use it to derive a harmonic from the 14MHz crystal....??

 

Cheers,

Leslie

Share this post


Link to post
Share on other sites

So if I've got it right, 3 clock cycles @14MHz would be enough (150ns < 67ns x 3 = 201ns) but you can read it only on the fourth cycle, right?

So for example, assume you are in mode "TEXT 80" and raster is on the first row just before text area in the left border zone. This is what I imagine the things that are happening:

(The VDC reads characters ahead of time, 1 column before they get actually displayed.)

Raster is at Y=0 and X=-16 in screen coordinates

|BORDER |BORDER |COL0   |COL1   |COL2   |       
012345670123456701234567012345670123456701234567  <-- time slot T=F14M mod 8
VVVV----VVVV----VVVV----VVVV----VVVV----VVVV----  <-- V = video has bus
----CCCC----CCCC----CCCC----CCCC----CCCC----CCCC  <-- C = CPU has bus
-------XRRRY----XRRRY----XRRRY----XRRRY----XRRRY  <-- reading character from RAM

T=7     (X) The video controller calculates the RAM address of the character to read (&HF800)
            and puts it on the address bus at the start of next CPU cycle.
T=0     (R) RAM reading starts
T=1,2   (R) ram is reading
T=3     (Y) 67ns*3 = 203ns seconds passed, RAM data is ready. 
            RAM is read and transferred into a register for displaying on 
            the successive screen cell when T=0,1,2,3,4,5,6,7

Is that a reasonable model ?

I still don't get how /RAS and /CAS are not aligned with F14M ... perhaps there is some sort of delay circuit involved ?

I'm also documenting the GA1 pins, there are lots of unknowns ("?"):

PIN        PORT   Meaning
-----------------------------------------------------
MA[7:0]    OUT    memory address sent as ROW / COL via multiplexers
A[15:14]   INOUT  address lines
BA[17:14]  ?      ?bank address. [17:16] connected to pin [44,42] ?
CVAM       OUT    ?cpu/video address multiplex; can disable the address multiplexer output
AX         OUT    address multiplex, A[15:0] address bus down to the MA[7:0]
D[7:0]     INOUT  data bus
/ROMCS     OUT    ROM select
F3M        ?      ? 3MHz signal?
F14M       IN     14.77873 MHz input from HSYNC delay circuit
F17M       IN     17.73447(5) MHz input from XTAL
/TOPBK     ?      ?connected to pin 34?
VDD        ?      ?connected to 5V?
VDD        ?      ?connected to 5V?
FRSEL      ?      ?connected to 5V?
/GRESET    ?      ?connected to 5V?
/IO        OUT    memory mapped IO, When 0 D[7:0] are from 74LS244 buffer (CASIN cassette input + keyboard KD[6:0])
/WAIT      OUT    cpu wait (0=cpu waits)
/MREQ      IN     cpu memory request
/IORQ      IN     cpu I/O request
/WR        IN     cpu write
/RD        IN     cpu read
CPUCK      OUT    3.6946825 MHz cpu clock (F14M/4)
RD[7:0]    OUT    character to read from charset ROM. Controlled by CGS. 
REMOTE     OUT    remote control, tape motor (not connected)
CAPLK      OUT    caps lock led
BUZZER     OUT    buzzer, the internal speaker output
CGS        OUT    character graphics select. When 1 RD[7:0] forms the charset ROM address (via a 74LS273 register)
/RAS       OUT    RAM row access strobe
/RAMW      OUT    RAM write
/CAS1      OUT    RAM column address strobe
/CAS4      OUT    ?not connected (column address strobe?) 
/CAS5      OUT    ?not connected (column address strobe?)
VA         OUT    selects the 0-7 row of the character in the charset ROM (connected to CGA[2])
VB         OUT    selects the 0-7 row of the character in the charset ROM (connected to CGA[1])
VC         OUT    selects the 0-7 row of the character in the charset ROM (connected to CGA[0])
CGD[7:0]   IN     character graphic data. The character bitmap read form the charset ROM.
GT         OUT    graphic table. Selects (ENG/GER/FRA) on the charset ROM via CGA[12:11] (how?)
R          OUT    red 
G          OUT    green 
B          OUT    blue
L          OUT    luminosity (0=dark colors, 1=light colors)
/HSYNC     OUT    horizontal sync
/VSYNC     OUT    vertical sync, triggers also CPU interrupt via /INT
CHROMA     OUT    chroma signal
CBUST      OUT    color burst
CASOUT     OUT    cassette output
VSS        NC     connected to GND
VSS        NC     connected to GND

Share this post


Link to post
Share on other sites

 

So if I've got it right, 3 clock cycles @14MHz would be enough (150ns < 67ns x 3 = 201ns) but you can read it only on the fourth cycle, right?

 

So for example, assume you are in mode "TEXT 80" and raster is on the first row just before text area in the left border zone. This is what I imagine the things that are happening:

(The VDC reads characters ahead of time, 1 column before they get actually displayed.)

Raster is at Y=0 and X=-16 in screen coordinates

|BORDER |BORDER |COL0   |COL1   |COL2   |       
012345670123456701234567012345670123456701234567  <-- time slot T=F14M mod 8
VVVV----VVVV----VVVV----VVVV----VVVV----VVVV----  <-- V = video has bus
----CCCC----CCCC----CCCC----CCCC----CCCC----CCCC  <-- C = CPU has bus
-------XRRRY----XRRRY----XRRRY----XRRRY----XRRRY  <-- reading character from RAM

T=7     (X) The video controller calculates the RAM address of the character to read (&HF800)
            and puts it on the address bus at the start of next CPU cycle.
T=0     (R) RAM reading starts
T=1,2   (R) ram is reading
T=3     (Y) 67ns*3 = 203ns seconds passed, RAM data is ready. 
            RAM is read and transferred into a register for displaying on 
            the successive screen cell when T=0,1,2,3,4,5,6,7

Is that a reasonable model ?

 

I still don't get how /RAS and /CAS are not aligned with F14M ... perhaps there is some sort of delay circuit involved ?

 

I'm also documenting the GA1 pins, there are lots of unknowns ("?"):

PIN        PORT   Meaning
-----------------------------------------------------
BA[17:14]  OUT    bank address. [17:16] connected to pin [44,42]
/TOPBK     ?      ?connected to pin 34?
VDD        IN     5V Supply voltage
FRSEL      ?      ?connected to 5V?
/GRESET    IN     Power on RESET input. connected to 5V through RC circuit.

 

 

Timing diagram looks reasonable to me, but all guesswork till we get a scope/analyser on the real machine :)

 

I've added a couple of descriptions to the pin table.

Not sure what FRSEL and /TOPBK are meant to do?

 

 

RAS and CAS *are* aligned to the 14MHz clock.

 

*RAS, *CAS, *AX will all likely be generated by a state machine circuit in the VLSI chip.

 

Looking at the timing diagram, imagine that the Video "slot" is divided into 8 distinct sections, split on each clock edge of F14M.

 

State 0 begins at the rising edge of F14M, at the start of the video "slot"

 

Here is what happens at each clock edge:

 

0: Assume that MA7:0 outputs are stable and hold the video ROW bits.

*RAS goes low, clocking the ROW bits into the DRAMs.

Access time for the DRAMs begins now.

 

1: *AX goes low. MA7:0 are now outputting the COLUMN data bits

 

2: *CAS goes low, clocking the column data into the DRAMs.

Difficult to tell from the diagram whether CAS is generated from clock edge 2, or by a delay line attached to clock edge #1.

Either would suffice.

 

3-4 do nothing, maintain state

 

5: RAS goes high

 

6. *CAS and *AX both go high.

Video section will most likely sample RAM data here. (approx 201ns after the falling egde of *RAS)

 

*MREQ from the Z80 may go low here if the CPU is trying to initiate a read cycle.

With AX high, the multiplexers will be selecting the ROW data of the Z80 address bus in readiness for the CPU cycle.

 

7. do nothing, maintain state

 

----

 

CPU slot is basically the same as the video slot.

 

All data to/from the DRAMs goes through the VLSI chip on the RD7:0 lines.

 

Presumably, the VLSI chips latches CPU read/write data, and presents it to the CPU during the CPU slot.

 

It doesn't appear that wait states are inserted for ROM reads or keyboard reads either?

 

It also isn't possible to tell from the diagram when the VLSI chip reads the character generator ROM/latch (2764/74LS273).

Suspect it does that during the CPU "slot" when it has free access to the RD7:0 lines.

 

 

We badly need a full scan of that technical manual ;-)

 

Cheers,

Leslie

Share this post


Link to post
Share on other sites

I think the read cycle is much shorter than 8 cycles @14Mhz.

If you look at the diagram in the manual, you can see that *RAS, *AX and *CAS go low in sequence in just one clock cycle, not 3 (green box in the picture, I moved *AX between *RAS and *CAS so the falling sequence is more obvious). Also, they get high in one cycle (red box).

 

post-31739-0-55352400-1556964921_thumb.jpg

 

From the picture they don't seem to be aligned with the falling edge of F14M either, suggesting they are not driven by a state machine on the @F14M clock, but by a delay line.

IMO, reading starts at the green cycle (T=0) and terminates on the blue one (T=3) where the character is read and the address of the next one is put into a latch, to be presented later at the end of the CPU slot. Which makes sense because with 4 cycles you leave the bus free for the CPU slot.

Regarding the wait states on ROM or IO access I am going to write a small test program to be run on the real hardware.

I updated the pins description, thanks. FRSEL could be "frequency select" perhaps?

Share this post


Link to post
Share on other sites

update:
- ROM readings are put on wait states the same as RAM
- I/O reads are NOT put on wait

I checked that with a small program using the VSYNC interrupt as reference, measuring how much raster lines does it takes to execute a reading loop

Share this post


Link to post
Share on other sites

I think the read cycle is much shorter than 8 cycles @14Mhz.

 

If you look at the diagram in the manual, you can see that *RAS, *AX and *CAS go low in sequence in just one clock cycle, not 3 (green box in the picture, I moved *AX between *RAS and *CAS so the falling sequence is more obvious). Also, they get high in one cycle (red box).

 

attachicon.gifclock_diagram.jpg

 

From the picture they don't seem to be aligned with the falling edge of F14M either, suggesting they are not driven by a state machine on the @F14M clock, but by a delay line.

 

IMO, reading starts at the green cycle (T=0) and terminates on the blue one (T=3) where the character is read and the address of the next one is put into a latch, to be presented later at the end of the CPU slot. Which makes sense because with 4 cycles you leave the bus free for the CPU slot.

 

Regarding the wait states on ROM or IO access I am going to write a small test program to be run on the real hardware.

 

I updated the pins description, thanks. FRSEL could be "frequency select" perhaps?

 

 

 

I didn't say 8 "cycles", but 8 clock edges (both rising and falling).

 

That gives you 8 distinct state changes within one CPU clock period.

 

---

 

Delay line is probably correct for the generation of the *CAS falling edge.

 

Data sheet for the 4164 DRAM says the max RAS to CAS delay is 75ns for the 150ns part.

 

Period for the 14.7MHz clock is 67ns, which would be cutting it a bit close.

 

---

 

 

That's good to know that ROM reads also get a wait state inserted, even though it isn't necessary.

 

Regards,

Leslie

Share this post


Link to post
Share on other sites

Ok "edges" and not cycles :-) sorry

What about ROM access times? Is it 250ns? That would be a problem for our theoretical model because it would require 5 cycles?

Perhaps the 8bit register (74LS273) between the charset rom CGA[10:3] and the RD[7:0] is involved in some way to help save one cycle?

Share this post


Link to post
Share on other sites

What about ROM access times? Is it 250ns? That would be a problem for our theoretical model because it would require 5 cycles?

 

Perhaps the 8bit register (74LS273) between the charset rom CGA[10:3] and the RD[7:0] is involved in some way to help save one cycle?

 

 

 

I can see 250ns EPROMS are fitted in the pic above.

 

If the ROM read cycles get the wait state the speed doesn't really matter.

 

Read will be initiated in one CPU cycle, the ROMs will be read in the next CPU cycle.

 

---

 

Yes, the LS273 will latch the output of the Character Generator.

 

We just have no idea when in the cycles the VLSI actually reads that data.

 

Will probably have to measure it with a scope to be sure.

 

At a guess I would say it is read during the section you marked in blue during the video "slot".

 

That is the only time you can guarantee that the DRAMs are not driving the RD7:0 lines.

 

Cheers,

Leslie

Share this post


Link to post
Share on other sites

I initiate DRAM read at time slot T=0 and complete at T=3. But ROM reading can only start at T=4 and thus the data isn't ready for the last time slot available, T=7.

I don't know how this can be solved, perhaps there's a way to make ROM start at the same time DRAM is read, on the same cycle. Is that possible?

For the moment in my FPGA implementation I assume ROM access time same as DRAM, until we find how it really works.

I mostly finished the video generator, all TEXT and GR modes are working (pictures attached).

post-31739-0-04334900-1557085229_thumb.jpg

post-31739-0-46302000-1557085254_thumb.jpg

  • Like 1

Share this post


Link to post
Share on other sites

I initiate DRAM read at time slot T=0 and complete at T=3. But ROM reading can only start at T=4 and thus the data isn't ready for the last time slot available, T=7.

 

I don't know how this can be solved, perhaps there's a way to make ROM start at the same time DRAM is read, on the same cycle. Is that possible?

 

For the moment in my FPGA implementation I assume ROM access time same as DRAM, until we find how it really works.

 

 

 

 

Hi Nippur72,

 

From an FPGA point of view, there is nothing to solve.

 

I assume you will but the LASER ROM image inside a Block RAM on the FPGA?

 

Use the 4 BA bits to determine which block is being accessed.

 

Read the SDRAM and ROMs in parallel.

Z80 can access the ROM, while video section reads from SDRAM.

 

PAL screen output looks good.

 

Cheers,

Leslie

Share this post


Link to post
Share on other sites

my concern about the charset ROM is to make it work exactly like the original, facing the same issues that VTL engineers had 30 years ago :-) It's a good way to learn. But of course in my FPGA implementation the ROM it's a block RAM so it's easily read in one cycle.

The RAM is a bit tricky because the space left on the board is scarce so I use the external SDRAM chip, faster than the Laser RAMs but you still need to emulate the /WAIT states if you want video and CPU read from the same chip.

I think I've found the right numbers regarding the video generation, the screen is 952x312 (952 being a multiple of 8) resulting in a frame rate of 14778730 / (952 * 312) = 49.7560129821 which is what I measured experimentally.

  • Like 1

Share this post


Link to post
Share on other sites

Very nice work! :)

 

I did a nosedive in the manual today/tonight to try and find out some questions!

 

/TOPBK= Top memory bank select, tells if there is ROM in the expansionport (ROM Cartridge or expansion), 4 possible banks, C to F, 16K each, can be switched in at window 0000-3FFF if you place right code in first four memory locations

 

FRSEL=50/60Hz select(PAL/NTSC?), connected to +5V in the schematic

 

Laser 500 memory map at start

0000-3FFF=16K ROM Basic (bank 0)

4000-7FFF=16K ROM Basic (bank 1), 16K Video RAM(bank 7), Memory mapped I/O(bank 2)

8000-BFFF=16K RAM(bank 4)

C000-FFFF=16K RAM(bank 5)

 

I wonder where bank 6 with supposedly 16K RAM is hiding in the memory map, can't really find out in the book/manual!?

Wonder how freely exactly you can assign a bank with which 16K window/16K socket? I have my 500 stored away for the moment, otherwise I would have tested to write to the I/O ports 40-43H and see whats happening!
There is a little program in the book that use unused RAM as a RAM disk with simple Load and Save commands!!
Laser 500 suprise me to be a more interesting computer than I tought, also the manual goes much more in deepth than before with other VTECH/LASER machines! Ok, that perhaps don't tell so much for an Asian computer, but anyway! I haven't still understand what market or machines VTECH really wanted to compete with!
You Italian guy/guys, where there ever any DIY projects for the Laser 350/500/700 in Italy, like expansion cards and so on? I'm little keen to build an AY2149 card add on, whould be nice! And maybe a SD-card interface to easily store things on! :)
There where a couple of Italian "Laser Computer Club" magazine to download at the archive.org, very nice, is there any more source to this magazines?
How many years/numbers in existens?

Please correct me if you see something misspelled or hard to understand, English is not my native language!

 

Have a nice day! :)

Share this post


Link to post
Share on other sites

Very nice work! :)

 

I did a nosedive in the manual today/tonight to try and find out some questions!

 

/TOPBK= Top memory bank select, tells if there is ROM in the expansionport (ROM Cartridge or expansion), 4 possible banks, C to F, 16K each, can be switched in at window 0000-3FFF if you place right code in first four memory locations

 

FRSEL=50/60Hz select(PAL/NTSC?), connected to +5V in the schematic

 

Laser 500 memory map at start

0000-3FFF=16K ROM Basic (bank 0)

4000-7FFF=16K ROM Basic (bank 1), 16K Video RAM(bank 7), Memory mapped I/O(bank 2)

8000-BFFF=16K RAM(bank 4)

C000-FFFF=16K RAM(bank 5)

 

I wonder where bank 6 with supposedly 16K RAM is hiding in the memory map, can't really find out in the book/manual!?

Wonder how freely exactly you can assign a bank with which 16K window/16K socket? I have my 500 stored away for the moment, otherwise I would have tested to write to the I/O ports 40-43H and see whats happening!
There is a little program in the book that use unused RAM as a RAM disk with simple Load and Save commands!!
Laser 500 suprise me to be a more interesting computer than I tought, also the manual goes much more in deepth than before with other VTECH/LASER machines! Ok, that perhaps don't tell so much for an Asian computer, but anyway! I haven't still understand what market or machines VTECH really wanted to compete with!
You Italian guy/guys, where there ever any DIY projects for the Laser 350/500/700 in Italy, like expansion cards and so on? I'm little keen to build an AY2149 card add on, whould be nice! And maybe a SD-card interface to easily store things on! :)
There where a couple of Italian "Laser Computer Club" magazine to download at the archive.org, very nice, is there any more source to this magazines?
How many years/numbers in existens?

Please correct me if you see something misspelled or hard to understand, English is not my native language!

 

Have a nice day! :)

@Platis thanks for looking into the manual -- yes VTECH did a great job in documenting the machine in detail, which is rather unusual if you look at the other homies.

 

So /TOPBK tells if there is any ROM in the expansion port, I remember some time ago a friend not on this forum made a test and found that A[15:14] on the expansion port are not used for the address itself but for selecting the bank. So if you want to make a cartdrige, A[15:14] selects bank C-F, A[13:0] address (16K) within the bank, and /TOPBK=0.

 

Regarding FRSEL, there are no NTSC machines around that I know of, but perhaps the chip was built with the ability to produce a NTSC signal as well. I guess FRSEL selects the numbers that are loaded into the counter registers of the video generator.

 

Bank 6 it's hidden to Basic and you can access it only after switching it in machine language. For this reason it's mostly unused. Basic holds there function keys assignments, indeed in Laser 350 (16K only) the function keys do not work (and do not exist either).

 

Back in the '80s we did not have the knowledge to make any expansion cards :-) An AY2149 would be nice, I know it's a common addon for the Laser 310/VZ300. For the VZs there is also a project with an SD card (arduino based), I guess it could be adapted to the 500 very easily since the expansion port seems to be the same between the two computers.

 

I did the magazine scans, unfortunately these are the only issues that survived.

 

 

Share this post


Link to post
Share on other sites

my concern about the charset ROM is to make it work exactly like the original, facing the same issues that VTL engineers had 30 years ago :-) It's a good way to learn. But of course in my FPGA implementation the ROM it's a block RAM so it's easily read in one cycle.

 

The RAM is a bit tricky because the space left on the board is scarce so I use the external SDRAM chip, faster than the Laser RAMs but you still need to emulate the /WAIT states if you want video and CPU read from the same chip.

 

 

 

Emulating some of the poor design decisions of early machines is not always a good idea ;)

 

You hobble your design with constraints to deal with hardware that isn't even there on the FPGA board.

 

How accurate do you want to make it?

 

---

 

You can easily get around the RAM bottle neck by using a dual port SDRAM controller.

 

Check out the one used in: https://github.com/NibblesLab/mz80b_de0

 

It's an emulation of the SHARP MZ80B on the Terasic DE0 board.

 

---

 

Nice of Platis to fill in some of the blanks!

 

Look forward to seeing a scan of that manual!

 

Cheers,

Leslie

Share this post


Link to post
Share on other sites

The fact that VTech released four more or less compatible models of the same platform: 350, 500, 700, 750 says something. I suppose all the different models should be put into a timeline, something roughly like this?

 

CreatiVision / 6502 [1981/82 ?]

VZ / Laser 1xx, 2xx, 300 / Z80 [1983]

Laser 2001 / 6502 [1983/84]

Laser 3000/CAT / 6502 [1983/84 ?]

Laser 310 / Z80 [1984]

Laser 350/500/700/750 / Z80 [1985]

Laser 128 / 6502 [1988]

Laser XT / 8088

 

Instead of just doing a MSX clone, VTech must've thought that 80 columns were important and went their own way with the 500 series. I thought the Laser 128 was released earlier on, almost so late that it possibly couldn't matter anymore.

 

For that matter, I've set up z88dk and am planning a programming session in the weekend.

Edited by carlsson

Share this post


Link to post
Share on other sites

Nice machines, my first computer was a Laser 200! This series was perhaps the worst in the whole Vtech range, but a good initiation computer ! Afterwards I wonder why the didn't use more of the capabilites of the 6847 chip. If you look at the Tandy CoCo you see there was more power in it than they used, like higher resolution and so. Probably because memory constrains, mine came with very little memory.

 

The Laser 128 was released earlier! https://en.wikipedia.org/wiki/Laser_128

 

One more thing about the Laser 500, if it isn't mention earlier;

Language of the keyboard is selected between english/german/france by a shorted pad in the keyboard matrix!

English=no shorted pad

Germen=A5 and KD4

French=A5 and KD5

 

@nippur72

Thanks for the scans of the Laser Club Magazines! :thumbsup:

Edited by Platis
  • Like 1

Share this post


Link to post
Share on other sites

my concern about the charset ROM is to make it work exactly like the original, facing the same issues that VTL engineers had 30 years ago :-) It's a good way to learn. But of course in my FPGA implementation the ROM it's a block RAM so it's easily read in one cycle.

 

The RAM is a bit tricky because the space left on the board is scarce so I use the external SDRAM chip, faster than the Laser RAMs but you still need to emulate the /WAIT states if you want video and CPU read from the same chip.

 

I think I've found the right numbers regarding the video generation, the screen is 952x312 (952 being a multiple of 8) resulting in a frame rate of 14778730 / (952 * 312) = 49.7560129821 which is what I measured experimentally.

 

 

Hi Nippur72, et al.

 

Been thinking about this a bit more over the last few days.....

 

Using the SDRAM means that you will have to allow for the refresh cycles which are quite different to the original 4164 DRAMs on the 500.

 

With the SDRAM chip on the mist board, each refresh cycle is around 70ns as far as I can see from the datasheet, with each row needing to be refreshed at least once every 32ms IIRC.

 

The dual port SDRAM controller would be best.

You can run the video side with the 14.778730MHz clock without any problem to generate the exact PAL signal, and have a cycle exact vertical interrupt.

 

That also allows simple modification should you decide you want to generate a VGA signal somewhere down the track.

 

Modify the SDRAM controller so it only allows refresh cycles to occur during the non-visible parts of the screen display. (HSYNC and VSYNC active),

and only during the VIDEO "slot".

 

I don't think that the 32ms maximum refresh interval time is necessarily something to worry about too much.

I've experimented in the past with delaying the refresh cycles to SDRAM chips to see how long they would retain their contents without a refresh cycle.

A couple of chips were able to retain their contents reliably for anything up to 4-5 seconds without a refresh cycle being allowed to occur.

Far in excess of the 32ms quoted.

 

The CPU side of the SDRAM controller is easy, as you no longer have to interleave with the video side.

As long as you insert one wait state to the Z80 for each RAM/ROM read/write, the timing should match the original machine exactly.

 

My Laser 500 has now been shipped, so as soon as it arrives I will be able to confirm your screen calculations of 952x312 precisely.

 

Cheers,

Leslie

Edited by RedskullDC

Share this post


Link to post
Share on other sites

Leslie, good your Laser 500 is on the way, can't wait!

As for the SDRAM on the Mist board, there is already a standard Verilog module for accessing it that solves all the timing problems. The SDRAM requires 8 clock cycles for a complete read cycle, but you can have a separate clock running at x8 frequency so you can make your reads in just one cycle of CPU clock. In my FPGA implementation I tried F14M x 8 (118 Mhz) and F14M x 2, they do both work (of course the x2 requires to "interleave" the reads).

Here's a screen of the VDC reading the video RAM in bank 7, taken from the emulator while running (CPU isn't working yet).

post-31739-0-06945900-1557681826_thumb.jpg

Share this post


Link to post
Share on other sites

crossposting from the Facebook group:

Thanks to the availability, tenacity and generosity of Carletto Provetto, today we finally have the Laser 500 manual completely scanned in PDF format: "Laser 350/500/700 Main Unit Manual".

You can download it temporarily at the following link: 
www.radioedintorni.it/Appo/laser.pdf

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I believed the ROMs did contain the code for reading and writing to disk, but there's the READ part only (at $0033 "READSC"). So the ROMs are meant just for being able to boot from disk (either VT-DOS or CP/M). I did a small test on the emulator and the "READSC" routine is used only once, VT-DOS 1.1 uses its own version. 

  • Like 2

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