VOGONS

Search

Common searches

Search results

Display options

Display options

Re: 8088 MPH: We Break All Your Emulators

Posted on 2020-03-09, 09:36

dr.zeissler wrote on 2020-03-09, 07:35: Does this demo work on any other than a cga card? It really needs a genuine IBM CGA card. I think there might be one or two clone CGA cards which have been reported to work as well but it definitely won't work on EGA/VGA/SVGA/later cards.

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-20, 08:08

in Milliways
Yes, I certainly don't expect to get around the memory access wait states. But just to confirm: both types do not halt the CPU. They only tie up the bus, right? If the CPU doesn't need to use the bus, all is ok? They tie up the bus, but when the CPU is doing an IO for the purposes of executing an …

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-19, 14:41

in Milliways
I know what I can do. I can use shl reg, cl instead of nops. Then the CPU won't need to access the bus and I can get variable length instruction timings. Perhaps the CGA wait states are really stopping the CPU from using the bus to prefetch the nops. I should have thought of this earlier. I have …

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-19, 14:35

in Milliways
But that's my point. Where are the CGA wait states? Why can't I run nops during those wait states? Surely wait states only mean the CPU can't access the bus, not that it stops altogether (granted it has to do instruction fetch). I totally get that I can't initiate a stosb and then do a nop while …

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-19, 14:03

in Milliways
That would mean the numbers really don't add up. A raster is 509.6 cpu cycles. If we take 11 cycles for stosw (granted, I used the wrong number here) and just 12 additional cycles for the part of the access not already included in the stosw time, then 7 stosw's and 21 nops should take 161 + 63 = …

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-19, 12:13

in Milliways
I'm totally not convinced the 4 planes take longer. The reason is that in graphics mode 1, the memory for all four planes is written to, but only one of the planes is read. However, reading and writing take the same time. Replacing stosw's with lodsw's makes no difference to timings. But I will …

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-18, 22:21

in Milliways
The RAM is dual ported but that doesn't mean that the two ports are completely independent - the VDU controller still needs to tell the RAM which addresses to send to the raster when. That is easier to do if all the VRAM control logic is derived from the same clock, i.e. the one that comes from the …

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-18, 22:14

in Milliways
The reason why some references say 11 cycles for STOSW and some say 15 is that the former are for 8086 and the latter for 8088 - there is an additional 4-cycle penalty on 8088 due to the narrower bus. STOSW without a REP prefix is documented as being 15 cycles on an 8088, but I measured it as 16 …

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-18, 20:08

in Milliways
Ah, I think I've figured it out. The VRAM in the PC1512 consists of two 41264-15 chips, each 64k x 4 bits. This is dual-port RAM designed for video buffers, with a serial output for the raster as well as random input/output for the CPU. The refresh cycle of the RAM is 4ms (just under 63 scanlines), …

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-17, 17:43

in Milliways
I did consider using the PIT. As I mentioned in the video, I actually got into this by trying to optimise the amount of work that could be done between writes to CGA memory. I later realised the PIT could work, but I think interrupts need to be on for that right? I reasoned that this would just …

Re: Raster bar implementation on Amstrad PC1512

Posted on 2020-02-17, 11:00

in Milliways
This is really cool! I didn't know that the display enable bit was replaced with a toggle in the PC1512. I was surprised by this at first but it actually makes sense. The purpose of the display enable bit was to avoid snow, and the PC1512's display adapter doesn't suffer from snow. So you want to be …

Re: EGA/VGA half clock vs character width?

Posted on 2019-11-08, 07:09

I don't think that's supposed to be happening? Do you know anything about the timings of the 800x600 32K/64K modes? I don't know the precise timings, but such a wide overscan seems wrong to me. I'd expect the ratio of active area to overscan to be similar to 640x480 mode. And the overscan size …

Re: EGA/VGA half clock vs character width?

Posted on 2019-11-04, 08:31

DCR is the easy one because everything else is derived from this dot clock. So when it is set to 1, everything on the screen is stretched by a factor of two horizontally. This is used for 40-column text mode and 320x200x16 mode. A character in these modes is still 8/9 dots, but the dots are twice as …

Re: EGA/VGA half clock vs character width?

Posted on 2019-11-03, 22:56

I'm not quite as familiar with the internal workings of VGA as I am with CGA, so I might be saying something completely stupid here... but is it possible that you're on completely the wrong track with the "4 dot clocks" thing? I'm not sure that a 4 dot clock is used in any significant way inside the …

Page 2 of 28

Go to top of page Go to top of page
Close window
Close window