nippur72 Posted May 2, 2019 Share Posted May 2, 2019 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?). Quote Link to comment Share on other sites More sharing options...
RedskullDC Posted May 2, 2019 Share Posted May 2, 2019 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 Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 3, 2019 Share Posted May 3, 2019 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 ... ? Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 3, 2019 Share Posted May 3, 2019 (edited) 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? Edited May 3, 2019 by nippur72 Quote Link to comment Share on other sites More sharing options...
RedskullDC Posted May 3, 2019 Share Posted May 3, 2019 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 Quote Link to comment Share on other sites More sharing options...
RedskullDC Posted May 3, 2019 Share Posted May 3, 2019 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 Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 3, 2019 Share Posted May 3, 2019 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 Quote Link to comment Share on other sites More sharing options...
RedskullDC Posted May 4, 2019 Share Posted May 4, 2019 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 Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 4, 2019 Share Posted May 4, 2019 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). 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? Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 4, 2019 Share Posted May 4, 2019 update:- ROM readings are put on wait states the same as RAM - I/O reads are NOT put on waitI 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 Quote Link to comment Share on other sites More sharing options...
RedskullDC Posted May 4, 2019 Share Posted May 4, 2019 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). clock_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 Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 5, 2019 Share Posted May 5, 2019 Ok "edges" and not cycles :-) sorryWhat 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? Quote Link to comment Share on other sites More sharing options...
RedskullDC Posted May 5, 2019 Share Posted May 5, 2019 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 Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 5, 2019 Share Posted May 5, 2019 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). 1 Quote Link to comment Share on other sites More sharing options...
RedskullDC Posted May 7, 2019 Share Posted May 7, 2019 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 Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 7, 2019 Share Posted May 7, 2019 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 resulting in a frame rate of 14778730 / (952 * 312) = 49.7560129821 which is what I measured experimentally. 1 Quote Link to comment Share on other sites More sharing options...
Platis Posted May 8, 2019 Share Posted May 8, 2019 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! Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 8, 2019 Share Posted May 8, 2019 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. Quote Link to comment Share on other sites More sharing options...
RedskullDC Posted May 8, 2019 Share Posted May 8, 2019 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 Quote Link to comment Share on other sites More sharing options...
carlsson Posted May 8, 2019 Share Posted May 8, 2019 (edited) 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 May 8, 2019 by carlsson Quote Link to comment Share on other sites More sharing options...
Platis Posted May 8, 2019 Share Posted May 8, 2019 (edited) 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! Edited May 8, 2019 by Platis 1 Quote Link to comment Share on other sites More sharing options...
RedskullDC Posted May 12, 2019 Share Posted May 12, 2019 (edited) 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 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 May 12, 2019 by RedskullDC Quote Link to comment Share on other sites More sharing options...
nippur72 Posted May 12, 2019 Share Posted May 12, 2019 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). Quote Link to comment Share on other sites More sharing options...
nippur72 Posted July 10, 2019 Share Posted July 10, 2019 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 1 1 Quote Link to comment Share on other sites More sharing options...
nippur72 Posted November 14, 2019 Share Posted November 14, 2019 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. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.