So I programmed the EPROM chip, but I hadn't the time to take out my only MDA/CGA/EGA monitor to test if the card actually works ... Maybe I'll have the time thursday or the next week-end.
Yes, that's me, with my Commodore PC20-III.
I also did one with an ATi Small Wonder, but its colours are all wrong in the 16-colour mode: https://youtu.be/eRVwYCq8X5w
The colors in that video look suspiciously like the effects of a phase offset of n×90° between assumed and real NTSC color sub-carrier, namely swapped and/or inverted redness and blueness components.
You are apparently not the first one to run into that problem: https://youtu.be/BdhvIfmRtvQ?t=393
But since that version of Commander Keen is a mod, anyway, there is still hope.
EDIT: In this particular case, both, the redness and the blueness component, are simply inverted.
Yeah a year has passed ... But anyways so after some tests, the card manages to display something, except it looks like this
Now this doesn't look normal at all. However I can recognise the text that's supposed to be there in that gibberish (like, when the DOS prompt is displayed, there's some gibberish on the left that is the same length as the DOS' prompt) so it works but it doesn't show the right things.
I doubt my flash is bad or that the ROM has the characters put at the wrong places though. This is the plantronics graphic mode and the same kind of thing happen but differently : .
This is supposed to be a black screen with a small green snake and randomly placed red dots. (This is my little asm project : [Game dev] Snake8088 (temporary name) and no it's not a programming error, this works well on my ati small wonder).
What's even weirder is that these green bars do not always show up and also that considering how my game works, that these bars are "physically" in the ram (my snake dies when it hits a green pixel, so when it hits a bar, it dies). At first I thought it was bad ram, but these photos have been taken after buying new ram and before that it was doing the exact same thing.
Now the card seems to react to the computer's activity to some degree (colors may change and some characters are changing in some spots when there's disk activity).
I don't have any other solutions now. What would you suggest to do next to save this card
If you are sure about the data integrity and data layout, then maybe it is a pinout problem.
27C256 EPROMs and 28C256 EEPROMs, for instance, have a slightly different pinout. Not different enough to destroy the chips, but different enough to result in garbled output.
I made that mistake with a homebrew Gameboy cartridge a couple of years ago.
Yeah but this is the eprom the card came with, and it shouldn't do anything in graphic mode.
Actually, it seems that the last bit is turned on constantly in RAM (looking at the ASCII table, "@"'s code is 1000 0000, and in plantronics mode that means that every 4th pixel will be a bright green colored pixel which corresponds to the pattern I can see).
Something must be off between the RAM's output and the PVC4 chip.
Did you test the RAM chips? And did you check the data lines, if you think that one bit is always 1....
I see two bodge resistors near the RAM chips. Where do they lead to?
YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC
I found that "@" pattern strange, and the pattern I saw in my own game also makes me thinkg there's a stuck bit in the RAM.
Since the RAM was fine, all there was left to check were the data lines just like @root42 told me.
So I took a schematic of the 4464 RAM chips, I fired up my meter in ohm meter position and started tracing.
This is what I came up with :
The red traces I draw are the one I checked with my meter. The blue one is one that *should* be there but isn't. It looks like I'm on the right path 😁
So I checked the unconnected pin on the chip and checked where it was going.
On the back of the card, I found this trace :
(Red is the visible part of the trace, blue is where the trace goes after the via). Bingo, that's exactly the data pin I was suspecting, it's D2 on the second chip.
And check this out !
Yeah that looks bad.
Now what's really strange is the break in the right circle I drew ... It looks like a misprint from the factory 😮. Was this card considered as defective since its creation ?
Now that's weird, because that thing really looks like a memory error, how fixing a trace for a data line that was definitely broken wouldn't fix anything ?
Then after talking to other people, they suggested me to test the snake game again, because maybe the character ROM I burned wasn't the right one.
Could this be it ?
Let's try it out !
Hey that looks correct now !!
So my fix actually fixed something, but it seems this card has other problems (now that I think about it, maybe the ROM I flashed is fine, but the data lines between the ROM and the paradise chip are also faulty ?? I'm gonna check that right now !!). I made some good progress today 😁
Edit : all traces between the ROM and the controller seem good, so I guess the flash is just wrong. Does anyone have a character ROM from a paradise PVC4 card ?
It was not uncommon to have boards with EPROM address and/or data lines "scrambled" with respect to the datasheet, for either data protection or routing convenience. If that's the case here, you will need to rearrange the data in the EPROM to match the card.
Hmm, how could I fix that ?
Maybe a ROM with each character representing their respecting hex value and a DOS program that would display every characters from 0 to 255 ?
Looking at your second to last screenshot again, I don't think that is actually the case here. It looks like the card is expecting an 8x8 font but is reading the data for an 8x14 font.
It was not uncommon to have boards with EPROM address and/or data lines "scrambled" with respect to the datasheet, for either data protection or routing convenience. If that's the case here, you will need to rearrange the data in the EPROM to match the card.
EPROMs were also used as address decoders.
That's because ouput state depends on the inputs.
So with the right ROM patterns, it's possible to form a simple decoder/encoder unit.
If done right, it can be crazy fast.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
Deksorwrote on 2022-06-27, 22:39:Well I tried a different ROM and that's what I get now :
https://media.discordapp.net/attachments/784081115505229837/99110943945 […] Show full quote
Well I tried a different ROM and that's what I get now :
Same pattern, but at least the characters are in the right font (I tried "CGA card for PC Spirit" on minuszerodegrees)
How could I make my own CGA rom to test my pattern ?
You are getting close. Can you clear the screen and type A-Z uppercase and lowercase?
Now it doesn't seem perfect as I suspect some special characters are messing with the "cursor", but most of it is here. (The program starts after the second line, the mess on the second line is simply "A:\")
I can see that the first line is messed up. The last character of that line is probably "@" but it blends in the rest of the "@"s.
Looking at the ASCII table, it seems "@" is the 64th character and " " is the 32nd. So I guess one thing I could try is to somehow shift every characters by one address bit. Not sure how to do that precisely though.
I wish there was a nice editor for CGA ROMs 🙁
Also every character seem to be only the "even" ones (B, D, F, H ...) and I see characters from the other font being shown here.
Ok let's not celebrate too early, it's still wrong, but it's a great step in the right direction 😁
Yeah the special characters are not good.
I suspect half of the rom is swapped with the second font (the characters don't look exactly the same). At the very least now the card is usable to some extent 😁