VOGONS

Common searches


Search results

Display options

Re: Best CGA & Hercules games

Technically this game has fantastic effects that I never saw on cga on any other game: https://www.youtube.com/watch?v=SygD93F95js What effects in particular are you thinking of? I didn't notice anything particularly technically interesting about the game, but I'm always on the lookout for new CGA …

Re: UniPCemu cycle accurate 8088 implementation

What about just splitting the 8088 MPH speed test part into managable chunks for the bus sniffer(of course starting with a jump to get the correct start cache situation)? Like I said, that's the tricky bit. The queue and bus state also need to be in the right state for each instruction. If I can …

Re: 8088 MPH: We Break All Your Emulators

Just found out something: CGA applies the memory write waitstates when updating the memory mode(changing mapped memory layout)? So when updating the memory with the new layout(due to changing VGA memory mapping it uses) it sets the waitstate for the current instruction(which it shouldn't)! Not sure …

Re: UniPCemu cycle accurate 8088 implementation

Do you have some sniffer log of the metric cycle check done at the start of the demo(as well as it's starting address, perhaps the instruction jumping to it for the first time)? Unfortunately that's easier said than done - the ISA bus sniffer only has 2kB of RAM on the ATMega328 microcontroller …

Re: UniPCemu cycle accurate 8088 implementation

OK. But those 1-cycle startup after the start of IN/OUT, 2-cycle for non-DX IN/OUT BIU idle following that and 1-cycle waitstate on all I/O bus operations is correct? 8088MPH reports 1547 metric cycles now. The PC/XT motherboard imposes a 1-cycle waitstate on all port IO instructions, yes. As for …

Re: UniPCemu cycle accurate 8088 implementation

I've just been looking at https://github.com/reenigne/reenigne/blob/master/8088/8088.txt again. Pay no attention to that document - it's an older one and the timings there are just from the published ones if I recall correctly. https://github.com/reenigne/reenigne/blob/master/8088/xtce/xtce.h is …

Re: 8088 MPH: We Break All Your Emulators

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

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

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

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

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

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

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

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

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

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

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?

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 …

Page 1 of 27