Reverse Engineering the Video Chip of the IBM CGA Card (1981)
Vložit
- čas přidán 21. 01. 2023
- We try to non-destructively figure out the HD6845 chip used on some IBM CGA cards from 1981.
Lots of new glitches are found along the way, and we freeze snow in place for possibly the first time!
Many thanks to Sean Riddle who let me use his die shot of this chip:
www.seanriddle.com/6845/
Viler's Font website:
int10h.org/oldschool-pc-fonts...
Reenigne's blog:
www.reenigne.org/blog/adventu...
Here is a link to a document (heavily under construction) in which I describe the result of some of the experiments I've done so far. Bear in mind this document has a long way to go until completion.
github.com/wbhart/crtc/blob/m... - Věda a technologie
Im currently writing a clone of the 6845 in verilog for an FPGA and this video is super helpful, thanks so much :)
That'll be difficult to get perfect I would think. But you should be able to get the intended behaviour. There are some surprises when it comes to which counters reset off what comparator. And various things happen on some comparator going high and others on it going low. All that information is difficult to guess and varies from model to model.
Graphics gremlin project actually has a CGA in for a FPGA
I'm just wondering how long until we discover that these old machines could, in fact, run Crysis...
No chance
Well, someone just announced that they can in fact run Wolfenstein. They weren't the only ones working on that (successfully) either if rumours are to be believed.
@@PCRetroTech the Wolfenstein source code is public, and I've seen references to EGA compatibility or at least support at some point in development (I believe it only supports VGA?), however nothing about CGA. I've lightly studied the source code in order to see the possibility of making my own source port however the code quality is low and very DOS specific, requiring additional work to build comfortably on modern systems
@@kreuner11 Here's a link to a tweet about the CGA version, including a link to the code:
twitter.com/Jameshhoward/status/1616182105087557641
@@PCRetroTech ah, it is adding the support into the code
Very interesting stuff, nice to see that new secrets are still being discovered even after more than 40 years since the IBM PC was introduced.
This was great, very interesting. Started off with a clear explanation of how CGA works and then built on it. Doing manual DRAM refresh was a real eye-opener, I had never considered you could turn off the automatic process.
Thanks! I'm glad you enjoyed it.
When I got to 1:49, I initially could not hear what you were saying, because my brain was busy processing the fact that my eyes were now looking at a beautifully flicker-free and picture-perfect CRT recording. :D True story. :) Well done.
I can do better with the CRT filming these days, but wasn't able to do so in this video because I needed the audio to be synced with my hand movements, which created additional technical issues. But thanks for the feedback.
@@PCRetroTech I didn't even notice there was still room for improvement. It looked perfect to me, at least at first blush.
@@ropersonline No, after some time there'll be a bar go across. I also still can't film at 4k or 60 frames per second and I still can't 100% focus without Moire. I also don't have enough room to get rid of focus variations across the curved surface of the CRT. But I'm glad it looks acceptable as is.
This is neither here nor there, but there actually was a terminal which drew a character at a time, scanning each with tiny partial horizontal refreshes and then going on to the next character. Absolutely bonkers and if I ever find one in person, I want to catch it with a high speed camera.
Oh really. That is utterly crazy as you say. Let me know if you ever find one. I'd really like to see that!
@@PCRetroTech Computer Terminal Corporation (later Datapoint, to whom we owe the 8080 instruction set among other things) first made terminals before the availability of RAM chips, so they used shift registers. They weren't fast enough to reread all 80 bytes per scanline, so they had an unfortunately-named "diddle circuit" which would scribble down each full character in turn. I actually have a Datapoint terminal, non-working, but it's late enough to have RAM chips so I suspect it has a regular raster. I'll find out one of these days when I get it restored, and I'll let you know!
that also reminds me... i once saw a video about a vector-based computer! And what's more, it doesn't use a RAM-based framebuffer (that would have required way too much ram), but uses one of those funky storage tubes to store the screen.
And, after doing objectively too much crawling over my browser history, I found it, "Tektronix 4052 Fast Graphics demo" id Ju8e0Z6RjqE (don't want to post link to prevent the comment being bäñn'd)
@@FavoritoHJS I believe I've seen that before. Who knows where people find this hardware. I've certainly never seen it come up for sale.
@@dualityk That would be interesting. I wonder if there was some intermediate time where the two technologies overlapped or whether they switched to a normal raster as soon as RAM started to be used. That would be an interesting piece of computing history to figure out.
Thank you, great video.
Don’t forget the Aussie microbee uses the 6545 variant. It has some extra useful registers.
Your videos are incredible. And this just adds to the list. Thank you!
Thanks. I appreciate the positive feedback.
It'd be lovely to get a modern reproduction of this card, since the originals are becoming so collectible as to be hard to find in the wild. I tried 8088 Domination on my Tandy 1000 HX over the composite out, and while it did "work," the colours came out shifted in value (works just fine in b/w over the RGB port). The other demos go much deeper into utilizing the quirks of the IBM CGA card's hardware, which is why only the IBM CGA card will display them properly, and why those cards have gone up so much in value the past few years. Unfortunately, that also locks most of us out of enjoying these demos in person, except vicariously over CZcams.
I agree a modern reproduction would be a worthwhile project. IBM of course still exists as a company though, so I'm not sure it's going to happen. Sourcing MC6845's might also be an issue.
I think the demoscene must surely have also contributed to GUS soundcards becoming unobtanium.
@@PCRetroTech Not just Gravis, but 8-bit sound cards in general. I've taken to running 16-bit pre-PnP cards with the end hanging out of the 8-bit slot. Works just fine in most cases, as long as you watch which jumpers you set.
@@BlackEpyon Yes indeed, that is true. I have a couple, but not many 8 bit sound cards, mostly obtained at reasonable prices by sheer luck.
I was just considering all this news from the vantage point of FPGA recreations. It’s one thing to have a repro that does exactly what the card is supposed to do. It’s another thing entirely to build in all the quirks so it does the same thing as the real hardware when you do stuff you’re _not_ supposed to do.
@@nickwallette6201 You'd need to either completely reverse-engineer the Motorola 6845 gate for gate, and reproduce it in a CPLD, or source others that have been recovered from scrapped systems. Maybe Motorola would be amenable to licensing it for reproduction, or just put the schematics out as open source (since it's long obsolete). You could easily reproduce the glue logic into a CPLD, even the same one that's emulating the 6845. A question though is whether or not the newer static RAM would make a difference in these demos vs DRAM which needs to be constantly refreshed. I don't think it would, but I don't know enough about the "black magic" of how these demos work.
A newer card would definitely be a lot smaller than the original, but if it requires one or more CPLDs, that would likely rule out the release of a kit. It'd have to be pre-assembled, or at least the CPLDs provided in the kit pre-programmed. The alternative would be FPGAs. That would necessitate a custom BIOS for it, but those are a lot easier to program with a cheap EEPROM programmer than the CPLD would be.
I don't know. I'm fairly decent at laying out PCBs if you give me a schematic, but programmable gate arrays are an entirely new thing for me.
Great video! The BBC Micro (a popular UK 1980's computer) mostly had a HD6845, and the community has made some progress in reverse engineering its corner-case behavior. I see from your linked PDF that you're looking into how the chip decides it is on the last scanline of a frame. This particular logic is insane! We've found that the chip appears to launch a series of logic tests on each scanline (one per clock, that chain into each other). It is why the chip goes screwy if you set R0 to be less than 3. BBC emulators such as beebjit, jsbeeb, b2 can handle this, and need to in order to run some of the latest crazy demos. I would provide links, except CZcams is being difficult.
I've had a look at jsbeeb before, although whether it had this behaviour encoded at the time I don't know.
At the moment it is slightly hard without studying the CGA schematics intensively to disentangle the behaviour of the chip from that of the card. The HD6845 datasheet talks about "outputting noise" in some cases, and my current best theory is that when you let the noise out the card can trigger various behaviour. For example on other CGA cards the same noise doesn't trigger any unusual behaviour at all.
By the way, I have two HD6845 chips that go screwy for R0 < 3 and one that doesn't. Two of them have the same date code and it's not the two you think!
Always enjoy your videos, even though 90% of this went over my head I still can see the huge amount of work you've done to wrap your head around all the timings here to find out new weird things that good ol' CGA can do that I'm sure demosceners will appreciate. It's cool that you discovered some new glitches after your efforts, well done!
Thanks. I was aware this was a little more technical than the usual video on the channel. There's a small group that will be really interested in the details, so I tried to keep it all at a very general level here. Plenty of less technical stuff to come though. :-)
@@PCRetroTech I'm glad you kept a lot of the tech knowhow in, I may like to learn a bit more of how CGA works, like tinkering with the FPGA Verilig code of the Graphics Gremlin so this could be useful reference - maybe could mod it to replicate the Hitachi bugs! Still good to see a new vid, hope you're settling into life in the UK. Cheers!
@@mogwaay Momentarily I'll add a link to the video description of a document I'm writing. Bear in mind this is a work in progress and will probably be rewritten entirely before I'm done.
Wow, that was impressive. What I'd love to hear more about, or hear about more explicitly, maybe in a future video, is what parts of this are specific to the Hitachi HD6845, and what parts apply to any and all MC6845 versions or clones. Failing that, I'd love to know more about what glitches are possible on ALL 6845 versions/clones used in actual IBM CGA cards, as for better or worse (often worse), warts and single-ported RAM and all, the latter's common capabilities denominator are the de-facto standard.
The snow should be common to all IBM cards. All the half char glitches seem to be Hitachi specific. Glitches to the end of the scanline are common to all chips. That's about the long and the short of it.
legendary stuff
I already have looked in the shelf and found my ATI Mach8 card ;) ...I am ready for the next stuff THX!
I really enjoyed this, it was great, thanks!
Thanks Sam!
At 32:34 the dot-clock delay that is absent on the LSB but not for the other bits might be due to the propagation delay (such as extra capacitance) introduced by the added logic inside the chip that are absent on the LSB. It might prove useful to look at the decap reverse engineering notes :-)
So far I don't think the decap reverse engineering got far. As I understand it the project was more or less abandoned. But maybe someone is still working on it somewhere that we don't know about.
The 6845 CRTC is also used in a couple of early to mid 80s arcade games, one of them is Qix, which displays a whoppin' 256x240 with 256 colors, but only in the test menu. In game, it only uses like, what, 9 or 10 colors...
Interesting. I think I do recall that it had been used in arcade games, but I didn't know about Qix specifically. Very interesting info. I wonder if I can find a video of it online....
You do have the advantage with that particular hardware of having a much faster processor- the Motorola 6809.
@@douro20 Nope - you don't have a much faster processor, you have THREE of them 😀
and one is dedicated to the graphics, so you could say that Qix has a graphics accelerator... in 1981!
Qix has 64k of video RAM. The reason it can't use 256 colors ingame is that in this game you can draw shapes freehand in order to wall in a monster that kills you if it touches you while you're drawing. Now with 2 players, the machine has to memorize the drawings of both players at the same time, so it uses two bits per player which means that only four bits are left for anything not drawn-playfield related. But still, the game could use 19 colors or with clever trickery all 64.
Here's a video that includes the self test (at 5:50) czcams.com/video/WUPFSFqCLtk/video.html (btw. yes the monitor is on the fritz, but that's a design issue and appears to not be age related - our local monitor specialist says it doesn't like the sync pulses.)
The main CPU has 1k of RAM and runs the game logic. The sound CPU has no ram (6802, what was it 128 bytes? 256 bytes?) and runs the sound. The graphics CPU has1k of battery backed RAM (high scores, audits, probably work RAM too), 1k of fast palette RAM (so it can blank the other player's color bits) and 1k of communication RAM. My guess is the main CPU puts commands in there like draw a line from here to there, do a flood fill on this position, draw the sprite in ROM location &whatever and restore the playfield on the sprite's old position and tell me the color of the pixel at this position.
@@senilyDeluxe Very interesting machine. There are videos online showing the various boards, but so far no one has zoomed in with a decent camera that isn't shaking around all over the place and out of focus whilst shouting over the top of the video. If you have it open at some point, would love to see the internals more clearly with some of the chips pointed out. From the Taito documentation online I didn't even know it had more than one CPU and I didn't see mention of the 256 colour mode. I believe there was a later version of this game Qix ultra or something. Maybe the documentation on Archive.org doesn't match the cabinet you have?
As someone educated in the 1980s, I seem to recall the DRAM control circuit providing RAS requests and thus refresh to all the banks on each memory request, at least under certain conditions. Thus manual refresh should be doable with fewer accesses, consistent with the DMA controller only stealing 1/12 cycles to do the refresh.
That does seem like it ought to work. So long as it is possible for the CPU to cause the DMA controller to do a refresh of a row (in all banks) without the PIT needing to fire, then that should work. Unfortunately the PIT is out of sync with the CGA card in a way that cannot be controlled after reboot. I'll have to look into that solution, as it seems better than the current approach.
As the CGA circuit diagram is public, much guesswork can be eliminated. Another key trick is to try to reconstruct the published behavior of the CRTC chip using a minimum number of gates to get an idea of how the glitches happen, thus gradually reconstructing the internal design to predict glitches before trying them.
Reenigne has studied the CGA schematics in detail and much of what we know comes from that. However, there are still mysteries that will only be solved by attaching a sniffer, as precise timings are not always trivial to predict. The CRTC chip is unfortunately slightly more complex than we'd like. We have a rough idea of what it looks like in terms of gates, but we don't know what design the comparators used, what design the registers used, anything about propagation delays or what is in the interlace or skew circuitry which is just a single box in the schematic in the datasheet. There are also glitches which I didn't talk about that are temperature dependent or which vary from chip to chip.
@@PCRetroTech That's the thing with these glitches, you're at the edge of what is hardware and what is tolerance.
Reminds me of doing FLI on a commodore 64 :)
very interesting!!!! thx!
The HD6845 was a very simple videochip, but it almost looks like magic when this old thing is being pushed into doing new tricks. A few month ago I ordered one from China and I am going to do standard things with it. And it would be nice to let it do something more.
Given IBM had some trouble getting it to completely behave (as this video demonstrates) I wonder whether it will be easy or hard to do standard things with it. If you are a perfectionist you might not like some of the glitches it has (there's a list in the datasheet).
I have a video card for an Apple II with this chip so I looked it up and realized it’s also in my CGA card, in my first computer which I still have. I used it even though it was outdated from 1987 to 1993 and tried everything I could with it at the time. So the demo that came out blew me away seeing things I never knew were possible. I also got into doing electronics (thanks to Ben Eater videos) so I’m interested in learning about these video chips. I was looking over the data sheet and I’m tempted to take the one from the Apple and try out stuff with it on a breadboard.
I don’t think even the Peter Norton guide to the IBM PC got into the registers for these. I only knew that you called BIOS to set up video modes and then you could write to video memory.
@@drivers99 Ben's videos are great and I've been tempted to do the same!
Never had that problem on the AMSTRAD PC1512 which has now been scrapped.
Has anyone fooled the card into doing a half scan line to generate interlaced fields?
There were some reasonably successful efforts on the Atari machines, and I believe a bit more successful ones on the C64.
I always wondered why IBM did not make interlace an option. Probably due to the very modest video RAM on their OEM cards. Still... seems like it should be there, just unused.
The chip actually has a couple of interlace options. There's a few obstacles to overcome to get it to work on the PC. There's a demonstration of what happens in Jim Leonard's CGA Compatibility Tester, although that isn't the only way to operate it. Some cards seemed to actually have a working interlace option out of the box, but IBM decided not to support it well or at least to not document it if they did.
Could the glitch be associated with the X-Scroll and Y-Scroll registers.
I would think that an alternative to disabling the PIT for DRAM refresh would be to program it to run exactly once per scan line.
Otherwise, I was just realizing that frame-aligned register accesses could probably be used to fix the interlace mode timing so that interlacing would actually work as it's supposed to. Back in the day, I played with interlaced video, but the instead of outputting an extra half line per field, the 6485 would output an extra half line every other field. Back in the 1980s when I tried that, I found that setting the vertical hold knob just on the edge of losing sync could yield legible 50-row text on the CGA, but it was annoyingly touchy. Frame-synchronized register writes should be able to fix that, though.
Which one of the ASM files (if any) correspond to that 'frozen snow' effect? I'd love to test this in my emulator.
There isn't a file in the repo for that. The repo is mainly about code to reverse engineer the CRTC. But the same basic loop can be used for freezing snow. You just need to add a write to VRAM at the right moment in time. Getting it to work on other machines is a fiddle due to timing differences though. It's not something you can just run. But f you have enough assembly experience you should be able to figure the code out.
I wonder what kind of shenanigans might be possible with interlaced mode...
I know the card doesn't have the circuitry to make it useful as intended, but it might be useful to screw with the current character row so you can have another "pallete" for "320x100"...
EDIT: Also, how does the composite output handle mid-frame resolution changing and such stuff? Like, is color-burst and hsync even remotely acceptable?
That's an interesting idea re interlaced mode. There's some technical challenges to overcome to get that to work, but it's pretty involved so beyond the scope of a video like this. In fact, I'm leaving that stuff to Reenigne who seems to be the current expert on that.
I don't know much about composite mode, but generally resolution changes are not predictable (at the moment) and we are still researching how to do it smoothly. It's actually difficult enough to do between frames, let alone mid-frame. But maybe we'll get it sorted soon.
But screwing with the other values shouldn't be difficult (and I'm sure they do so in 8088MPH). Composite monitors are not so different to RGB monitors in operation. But I don't know the answer to your question about colour-burst and hsync. I've only done experiments on RGB personally.
good video, cga typical retro
Mario Brothers 3 on NES gets similar artifacts on the left and right sides of the screen you were demonstrating switching between 5 and 9 hdot widths. NES is of course not CGA but I wonder if they were playing similar tricks to make such advanced graphics at the time?
I'm not super familiar with the Nintendo hardware but I think that used a Texas Instruments chip that is quite different in design, so it would be a surprise if the glitches were related. However, a lot of that early hardware had to be very economical in transistor counts and so there were no doubt many glitches, and similar glitches, in many of these systems. Games tend to not use the hardware itself in a super technical way because that would make them way more difficult to get to market. They tended to rely more on software tricks to minimise memory usage and algorithms that would give good performance. That's a different style of coding, for the most part, to what democoders are doing nowadays in revisiting these old systems and pushing every glitch and technical feat out of the often poorly understood hardware.
@@PCRetroTech The NES Picture Processing Unit was a clean slate design if I'm not mistaken. Some games did do a ton of register manipulation to get higher resolution sprites than what was otherwise possible, like Batman and the two Metroid games.
SMB3 uses 2K of the NES internal RAM to hold a scrolling screen, which is enough for a screen 32 tiles wide by 60 tiles high, with four rows worth of memory used to set the attributes of every 2x2-tile region. The PPU normally displays a region that's 32 tiles wide by 30 tiles high, but can blank the leftmost tile. Unfortunately, when side scrolling, the screen still shows portions of 17 different 2x2-tile regions across its width. Cartridges can be wired to either use internal RAM for 32x60, 64x30, 32x30 plus 1Kbyte of shape RAM, or else use 4K of RAM in the cartridge for a 64x60 screen. SMB3 attempts to do 2d scrolling as well as it can be done without using external cartridge RAM for the tile map.
Nice video !
The snow tricks (which may not be useful) makes me think of the dots that show up at the bottom of the screen of the megadrive which apparently *could* be used ... if their appearance didn't change on a per console basis.
As for the next video, do I happen to know these cards (or at least some of them) ? :D
Yep, although there is another hardware video I plan to make that you don't know about. I made another hopefully interesting acquisition just before I left Germany. :-)
@@PCRetroTech Can't wait to see that :D
This registers are counters too, so maybe most significant one causes propagation change
I don't think the registers can be counters, or the values you put in them would be lost.
good video , i played it at night and fell asleep instantly and i am insomniac lately
i know you are entusiastic about the glitch hunt but it is far more technical to me i prefere if the solution has a purpose, not just blankets with holes . but i wish you luck finding a good use for snow characters and half drawn characters in the future
Amazing video as always. Very clever solution on handling dram refresh. Did you have to interleave your code across all 64k blocks to ensure all 640k was refreshed? I assume this trick would only work if you assume all machines had 640k and maybe then attempting the trick on a 256k PC would result in a memory address error? I suppose you could create code to first calculate available ram.
Could you sweep the 8086 stack pointer across all the 64k blocks to do a refresh or does the cpu not energize the stack locations when the pointer is assigned? Probably not. Clearly the pointer would have to then be set back to normal as well.
Has anyone ever used the cga ram area for extra ram storing code in off screen regions? Probably useless idea but curious. Maybe you could with ega in an off screen frame buffer? Yeah its slow ram.
Anyways what a great video. Always excited for you to drop another.
Yes, one has to put 256 bytes of code in each 64kb block (and alternate the addresses from 0 mod 512 to 256 mod 12 to catch all the 256kbit chips). But the code was just NOPs in my case as I didn't have much to do every frame and there was plenty of time left between the refresh procedures to get stuff done. Of course in a demo every single one of those bytes would be doing something useful and some!
Of course to do it carefully one would have to figure out how much of the RAM is populated. I don't know if one would get address errors. But one can of course check the settings of the switches (there's registers for this) and that should give you the RAM configuration.
No, one can't simply sweep the stack pointer to refresh the RAM. The CPU doesn't energise anything unless the RAM is read or written. Simply setting an address in a register won't affect the rest of the machine, unfortunately.
As for offscreen regions, there's just a few bytes (192 bytes per 8 kb bank to be precise), not enough for anything substantial unless in text mode. And it is very slow compared to system RAM due to the CGA wait states. I'm not aware of anyone who used it for anything useful.
Glad you liked the video.
I posted a positive comment later earlier, and I mentioned a technical document on which I work and which describes the reverse engineering of the CRTC of different manufacturers, used in particular in the IBM PC. (AMSTRAD CPC CRTC Compendium).
Did I contravene a rule for my message to be erased? I had given a link on my document, but I do not see or it can be problematic ... I try again without the links ...
Hi, that looks absolutely fantastic. Thanks for letting me know. Yes, CZcams deletes absolutely all posts containing links of any kind and various other things as well. I don't even see the posts myself any more. They just disappear instantly.
Anyway, I was able to find a link to the Compendium on the CPC Wiki. The link to the French one seems dead, but I found the English one further down. That is a very impressive piece of work!
My email address is in the community section of the channel if you want to get in contact (my email address doesn't delete links :-))
@@PCRetroTech Email sent ;-)
@@logonsystem6791 Thanks! I will try to reply when I catch up at work in the next couple of days. The video you linked is not working by the way. I think the video might be set to private. If they set it to unlisted I would be able to watch it if I had the link.
@@PCRetroTech Link corrected 🙂
@@logonsystem6791 Thanks!
This video is very interesting. In the 80's I ran into this timing problem when I wanted to fiddle with the CRTC registers and suspected the card bus and 8088 instruction latch.
I never would have suspected DMA, and I don't know how you disabled it?
Is it possible in software or do you have to make a hardware modification?
I'm working on a document that describes the behavior of different CRTC models within the Amstrad CPC architecture (Motorola, Hitachi, UMC).
I’ve created a portall that summarizes many tests
The CRTC Compendium 1.3 is available on the logon system website
Version 1.4 should be released in English soon.
This may be of interest to you.
Being precise with this component allows you to do amazing things.
It is possible to do, for example a vertical scroll at 1/64th of a pixel (and 1/128th must be possible too) . Some techniques also help to increase horizontal precision.
I'm going to read the Compendium very carefully, thanks. And I am really looking forward to version 1.4 with the info you mentioned, as that is particularly interesting.
As for DMA refresh, one just has to disable channel 1 of the PIT, which is what drives the DMA refresh. No hardware modification is required. It is software only.
There are other things that interfere with timing. The PIT cannot be synchronised in a reliable way with the CGA card (after a reboot the synchronisation will be changed). But you can simply avoid using the PIT.
There are also wait states from the CGA card which will interfere if you write to video RAM. They are totally predictable however (Reenigne describes the exact algorithm on his blog). And of course you can avoid them altogether by not writing to VRAM.
Other than that, as you can see, a perfectly quiet and reproducible system is possible as I show in my video. However, once you synchronise the CPU with the CRTC frames in the way you want, you have to do the whole procedure again if you want a different synchronisation (or add additional characters to your frame temporarily). This means you really only have control in a given frame down to the CPU cycle (3 hdots) not down to the hdot. That might be different on other platforms, I don't know.
@@PCRetroTech Thank you for this additional information. With the architecture of the amstrad CPC, it is difficult to be as precise as on a PC when writing registers because of the pattern imposed by the graphics circuit (called Gate Array and which reads the ram addressed by the CRTC to supply the pixels (with 1 µsec delay)) to the processor (basically the Z80A is put on hold by the GA). The only possibility of playing on the moment of writing is to use another instruction of I/O in the cycle T is positioned differently with regard to the pattern which I have just evoked. Writing at the limits is not necessarily always relevant insofar as certain conditions arm the resets to 0 of certain counters in advance (as is the case for counter C4 at the end of the frame with the Motorola or the Hitachi). In the compendium I think 1 hdot in your document is similar to a Pixel-M2, but I think you will make the link easily :-). On CPC this corresponds to 1 pixel of the 640 horizontal pixel mode with R1=40) which is supposed to be the fastest frequency for the Gate Array (0.0625 µsec). However, the compendium mentions some differences at the limits, but I haven't noticed any on C0=R1. What you call "to-imminent or from-imminent" is indicated as Rx.JIT in the compendium (JIT for Just In Time). There are also bugs on the writing of certain precise values at certain positions, which allow the activation of internal states unrelated to the register (for example on the CRTC 1 (UMC), position R5>0 on C0=R0 enables states such as video pointer update authorization and interlace parity management).
Impressive work around the sync stuff and CRTC glitches.
Snow was never really a mystery, there is a lack of bandwidth and the CPU wins a fight for access to RAM, meaning the video is displaying whatever data is on the databus at whatever address the CPU is reading/writing in video RAM.
When it comes to writing: the address bus is valid before the data is written and you're seeing that in the character snow being the original data before the CPU has had the chance to change the value, then by the time the video is reading the attribute byte it is seeing the data the CPU has actually written to the bus.
When it comes to reading both char/attr would be the same since no change is happening, you're just seeing whatever is at that address in both instances.
I'm guessing if the CRTC and the CPU aren't in perfect lockstep like you've managed that exactly what the CRTC sees as snow in char and attrib might be a bit more random though?
You're probably the first person to control the snow like that though via that precise timing technique and it's very cool to see it isolated like this.
Thanks for the comments. Yes, of course the RAM is not dual ported and/or static and there just weren't enough cycles to have the CPU and video card access at different times in the 80 column text mode.
If the CPU changes the address while the card is reading the RAM you get wrong data. I would guess the CPU gets to set the address correctly for writing, otherwise snow would persist in the same location.
@@PCRetroTech Yes, the CPU has priority access so the CPU will drive valid address/data. I haven't looked at the schematics yet but I assume some sort of priority encoder is used to prevent the CRTC gating its address signals onto the address bus when CPU is doing its access.
My mind is fuzzy on the issue but I think with the sega master system you could corrupt the VRAM if you wrote to the VDP too fast during active time. You can write it any time you like since there is a one byte FIFO between you and the VDP VRAM but if you write too often in active I think it can corrupt. The solution is you have to write a few NOPs between your writes during active time. When I wrote my tetris clone 'Bloki' for SMS I did 'unsafe' accesses in vsync and the rest of the reads/writes were done vi a 'safe' macro. Given a vast proportion of time is in active, the slow access is still very useful compared to a tiny access window in vsync. But then we're spoiled on the SMS we get frame interrupts, tiles and sprites! Since the SMS only has the one normal interrupt which is from video you get the satisfying thing that when you're done with your frame you just halt the CPU and your code will restart when vysnc comes around. 😛
Or are you saying that on reads the CGA does feed the CPU garbage data during active? I hadn't actually tested that. Seems strange.
@@neodonkey No, that doesn't happen as far as I know. I think you are right. The CPU gets priority, though I've not looked at the schematics either.
We need a lower cost CGA/RGB-to-VGA/HDMI convertor
There are cheaper ones out there. They just aren't as flexible I guess. You get what you pay for.
@@PCRetroTech Where? Link? Thanks!
@@Fezzler61 I think Necroware made one. I don't have a specific link, but maybe you can find things like this on secondhand websites.
Its funny how the video is 40:25 minutes long 😂 (if u dont understand it is a text mode)
CRTs emit a high pitched whine of somewhere around 15-16KHz... please remember to edit this out of future videos, this is upsetting my Umbreon ears :(
CZcams doesn't capture frequencies that high. CZcams also does not capture sine waves. The compression only records sounds with harmonic overtones, which it simplifies.
@@Peter_S_ Until my comment with links to screenshots get approved: I took this into audacity, looked at the spectrogram and did a frequency analysis. and there is ABSOLUTELY a 15.625KHz frequency while the CRT is being shown. you can tell from the spectrogram and confirm the exact frequency with the analysis (it is around 15.7KHz).. I also did a hearing test and confirmed that I can hear up to almost exactly 20KHz.
whatever you just said is wrong.
edit: tone generators are dumb, I can actually hear up to 21.5KHz. volume calibrated with a 1KHz tone.
Don't watch these videos with headphones. Because I noticed sometimes watching videos with headphones that show old CRT monitors, the 15kHz whine was much louder than having a real old CRT TV next to my ears. Like almost unbearably loud - and I actually like the 15kHz whine because that tells me "The TV is on" - and that's something good.
Because otherwise, the 15kHz is part of the deal. I grew up on that, my parents never complained, their parents never complained, and it appears they all really liked watching TV...
@@senilyDeluxe "Because otherwise, the 15kHz is part of the deal." Once upon a time I turned on a CRT TV and it immediately felt like my head was filled with the most insufferable screeching imaginable. It felt like my head was about to explode.
I think some sets are louder than others
@@LoganDark4357 That sounds like there was something wrong with your set (not your head :-) ). Some are indeed louder than others and size barely matters although color sets are generally louder than B&W sets, but even there are exceptions. I remember a 16 inch B&W mid 70s SABA that was louder than pretty much all my color sets. And then I have a 19 inch color Blaupunkt from '82 which I put into an arcade cabinet that was missing the monitor, it's so quiet, when the cabinet is closed you barely hear it at all. And then I have a 26 inch set with the same chassis that is unusually loud, but it has a replacement flyback, maybe that is the cause. And it's 110° instead of 90° so that certainly contributes.
I also have a 17 inch '81 color TV where the whine was uncomfortable. And it just felt /wrong/. The picture was fine though. After a few loud bangs I checked the insides and found the flyback to be hotter than what's normal and the tripler to be warm (these usually run cold). I replaced the tripler, the whine went back to normal and now pretty much nothing in that TV ever gets more than lukewarm after hours of operation (plus no
more loud bangs).
And now for the explanation of your head exploding: Sometimes, something inside the flyback (or the yoke or near both of these) starts resonating at half the horizontal frequency. I had that happen before on at least two sets and yes, if feels like your head is gonna explode. If that happens, nudge the set and hope it ceases, otherwise... don't use that set. Give it away (or better trade it in) or use it for spares.
there is such a thing called a datasheet provided by the manufacturer. so engineers csn use them. they are usually privided freely with schematics and such. have you heard of them?
The schematic in both the MC6845 and HD6845 contains black boxes for things like "Vertical Contol", "Linear Address Generator", "Interlace Control", "Skew control". As an engineer, you know how these circuits work do you? Or you can explain given a black box for "comparator" why the gate delays cause the glitches I mention in the video? Or maybe you can predict the new vsync glitch VileR found yesterday which is most definitely not listed in either datasheet, nor in the 272 page improvement that the Amstrad people have constructed?
I guess you've seen the "schematic" in the 8086 datasheet as well?
Maybe Ken Sherriff is just cribbing from the "schematic" in the datasheet. Probably Sean Riddle and co. don't really need to delid these things either. And no doubt Reenigne just had to read the "schematic" for the 8088 in order to write XTCE?
☹️ 'Promo SM'
if ((Y&1)==0){
Start_bank=B800,; Offset=0;
}else{
Start_bank=A800; Offset=0;
}