nippur72

this is very similar to what I get on my LG LCD TV; for some reason on the CRT it's better.

can you post a picture (here or on the group) ? In my experience, composite output to CRT screen is fair; on LCD is not so good because modern TV use post-processing. On the contrary, output with the Peritel/Scart (which you don't have) is incredibly clean and sharp.

the discussion moved to the Facebook group (which I think you already subscribed, right?) but not much activity recently. The only noticeable perhaps is the release of a Tetris game for this machine.

oh thank you I'll check it ? I'll compare it to the browser emulator which is pretty solid. BTW we have also an FPGA implementation for the MiST platform that is accurate as well, though it doesn't replicate the VLSI chip but emulates it at a functional level.

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.

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

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

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

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.

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

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?

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

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?

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

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?