What is one thing about a retro console/computer's specifcations that you would change?
Moderator: Moderators
- Individualised
- Posts: 310
- Joined: Mon Sep 05, 2022 6:46 am
What is one thing about a retro console/computer's specifcations that you would change?
I was thinking about the ZX Spectrum recently and how it's colour attributes are a bit of a waste. For those who don't know, the Spectrum is technically a 16-colour (or more like 15-colour, as it has 2 identical black colours) computer. However, in practice, it acts more like an 8-colour computer with extra steps, as you are limited to how you can use each of the 16 colours together. The worst part is, there was no real technical reason that the computer was designed like this, let me explain; this is due to the attribute table. Each 8x8 cell of the bitmap (the ZX spectrum is a bitmap-only computer and does not have text or tile modes) has an attribute and can have 2 different colours, one for the background and one for the foreground. Each attribute is 1 byte long.
So what's the issue? That nicely fits 2 4-bit values, allowing you to select any of the 16 colours for both the BG and FG, right? Well, it's not actually arranged like this. For some reason, the hardware designers thought it was absolutely necessary to include a useless "blink" attribute bit. This means that there are only 3-bits available per colour, plus an extra bit to select the "palette" (basically the darker or lighter colours), along with the blink bit. If they had not bothered to put in the blink bit, it would allow for much nicer graphics on the Spectrum, as a lot of games suffered due to this (you will notice a lot of games have jarring transitions between lighter and darker colours). Plus, had they done this, it would have meant they could have replaced one of the duplicate colours with a new colour too, such as brown, as they did on the rare NTSC Timex models.
So that, along with an older thread (viewtopic.php?p=258966), inspired me to ask the members here; what would you change about a retro console/computer's specifcations? It doesn't have to be the NES, it could be the SNES, or even a non-Nintendo console.
So what's the issue? That nicely fits 2 4-bit values, allowing you to select any of the 16 colours for both the BG and FG, right? Well, it's not actually arranged like this. For some reason, the hardware designers thought it was absolutely necessary to include a useless "blink" attribute bit. This means that there are only 3-bits available per colour, plus an extra bit to select the "palette" (basically the darker or lighter colours), along with the blink bit. If they had not bothered to put in the blink bit, it would allow for much nicer graphics on the Spectrum, as a lot of games suffered due to this (you will notice a lot of games have jarring transitions between lighter and darker colours). Plus, had they done this, it would have meant they could have replaced one of the duplicate colours with a new colour too, such as brown, as they did on the rare NTSC Timex models.
So that, along with an older thread (viewtopic.php?p=258966), inspired me to ask the members here; what would you change about a retro console/computer's specifcations? It doesn't have to be the NES, it could be the SNES, or even a non-Nintendo console.
Re: What is one thing about a retro console/computer's specifcations that you would change?
I would have made the EXT audio available to the cartridge on the NES. It is on the Japanese Famicom, but for no good reason, not on the US.
(it is accessible through the hidden port on the bottom, which requires cutting some plastic to even see it)
The front load NES design was a bad choice, and it made it more likely to fail to play. Should have been top down like nearly every other console.
(it is accessible through the hidden port on the bottom, which requires cutting some plastic to even see it)
The front load NES design was a bad choice, and it made it more likely to fail to play. Should have been top down like nearly every other console.
nesdoug.com -- blog/tutorial on programming for the NES
Re: What is one thing about a retro console/computer's specifcations that you would change?
I'd assume that the blink/flash bit existed for text based business software, which is what the ZX Spectrum was originally targeted for.Individualised wrote: ↑Sun Dec 04, 2022 11:54 am I was thinking about the ZX Spectrum recently and how it's colour attributes are a bit of a waste. For those who don't know, the Spectrum is technically a 16-colour (or more like 15-colour, as it has 2 identical black colours) computer. However, in practice, it acts more like an 8-colour computer with extra steps, as you are limited to how you can use each of the 16 colours together. The worst part is, there was no real technical reason that the computer was designed like this, let me explain; this is due to the attribute table. Each 8x8 cell of the bitmap (the ZX spectrum is a bitmap-only computer and does not have text or tile modes) has an attribute and can have 2 different colours, one for the background and one for the foreground. Each attribute is 1 byte long.
So what's the issue? That nicely fits 2 4-bit values, allowing you to select any of the 16 colours for both the BG and FG, right? Well, it's not actually arranged like this. For some reason, the hardware designers thought it was absolutely necessary to include a useless "blink" attribute bit. This means that there are only 3-bits available per colour, plus an extra bit to select the "palette" (basically the darker or lighter colours), along with the blink bit. If they had not bothered to put in the blink bit, it would allow for much nicer graphics on the Spectrum, as a lot of games suffered due to this (you will notice a lot of games have jarring transitions between lighter and darker colours). Plus, had they done this, it would have meant they could have replaced one of the duplicate colours with a new colour too, such as brown, as they did on the rare NTSC Timex models.
So that, along with an older thread (viewtopic.php?p=258966), inspired me to ask the members here; what would you change about a retro console/computer's specifcations? It doesn't have to be the NES, it could be the SNES, or even a non-Nintendo console.
If you think that's bad, look at the Sinclair QL, which has a blink bit in the 320x200 mode (aka the mode you wouldn't generally use in business software) instead of an intensity bit, leaving 3 bits for regular digtal RGB.
- Individualised
- Posts: 310
- Joined: Mon Sep 05, 2022 6:46 am
Re: What is one thing about a retro console/computer's specifcations that you would change?
You are probably right, but it begs the question as to how high of a demand for blinking text there was in business software that it required a dedicated hardware feature rather than it just being done in software, which would be trivial to do and also more versatile. I would have actually thought that having blinking text would be considering an annoyance by the users of such applications, but then again I guess there isn't much other ways to draw attention to something in a text-based application (probably why MDA and maybe CGA on IBM compatibles have the same thing).Catyak wrote: ↑Sun Dec 04, 2022 3:41 pm I'd assume that the blink/flash bit existed for text based business software, which is what the ZX Spectrum was originally targeted for.
If you think that's bad, look at the Sinclair QL, which has a blink bit in the 320x200 mode (aka the mode you wouldn't generally use in business software) instead of an intensity bit, leaving 3 bits for regular digtal RGB.
Re: What is one thing about a retro console/computer's specifcations that you would change?
These machines were not fast enough to easily blink text in software even in text mode... For example, look at how much difficulty Trixter's Monotone has with updating the screen. It'd be even worse on the Spectrum, where you'd need multiple writes for every grapheme.Individualised wrote: ↑Sun Dec 04, 2022 4:01 pm that it required a dedicated hardware feature rather than it just being done in software, which would be trivial to do and also more versatile.
Separately, I think the "blink" attribute dates to previous monochrome displays.
Re: What is one thing about a retro console/computer's specifcations that you would change?
CGA let you disable blink and replace it with High Intensity mode for background colors. Same method did not work on EGA/VGA.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: What is one thing about a retro console/computer's specifcations that you would change?
You can disable blink and enable high intensity background colors on EGA and VGA too, but the method is different from CGA.
Since we're talking about things we'd change about retro computers, I'd say the IBM PC really could have used a functional vertical retrace interrupt.
CGA doesn't have a vertical retrace interrupt. It would have been nice for games, but I guess a business machine doesn't need to play games.
EGA does have a vertical retrace interrupt, but it's broken. The status bit reports the status of the interrupt line, which means it reports an active interrupt when any device attached to that interrupt line is raising an interrupt. Some EGA clones have the status bit inverted, too!
VGA also has a vertical retrace interrupt, but only in Micro Channel PCs. Some VGA clones provided the interrupt in ISA PCs, but most either left it disabled by a jumper or didn't wire it up at all.
Since we're talking about things we'd change about retro computers, I'd say the IBM PC really could have used a functional vertical retrace interrupt.
CGA doesn't have a vertical retrace interrupt. It would have been nice for games, but I guess a business machine doesn't need to play games.
EGA does have a vertical retrace interrupt, but it's broken. The status bit reports the status of the interrupt line, which means it reports an active interrupt when any device attached to that interrupt line is raising an interrupt. Some EGA clones have the status bit inverted, too!
VGA also has a vertical retrace interrupt, but only in Micro Channel PCs. Some VGA clones provided the interrupt in ISA PCs, but most either left it disabled by a jumper or didn't wire it up at all.
Re: What is one thing about a retro console/computer's specifcations that you would change?
Looking at the schematics of PC CGA, I thought to change around some of the wires. which allows more selection of colours in graphics mode, allowing font selection in software, and a few other improvements, without needing to add more memory (I think even without adding other ICs, but maybe I misremembered and you do need an extra quad NAND or quad NOR or something like that). For one thing, the extra address bits of CRTC are used for extra modes, which also easily allows split screen, if you do not need scrolling. (However, maybe it is better to allow scrolling to wrap around and not using this for text mode)
Vertical retrace interrupt on PC also would be good.
I also think that NES/Famicom could have been designed better in some ways too, again there are some improvements which could be made without needing to add more memory/components, and only rewiring the existing ones.
Vertical retrace interrupt on PC also would be good.
I also think that NES/Famicom could have been designed better in some ways too, again there are some improvements which could be made without needing to add more memory/components, and only rewiring the existing ones.
(Free Hero Mesh - FOSS puzzle game engine)
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: What is one thing about a retro console/computer's specifcations that you would change?
the 128VDC has this same flaw, only it also uses the other bits for reverse, "underline" rather than allowing for both colours to be set per "block"
However for control software I 100% want a blink. If this computer is controlling a machine and there is an error or warning, I want that screen blinking.. without slowdown, without some random software bug stalling the CPU causing it not to blink. That is how Nuclear power stations melt down.
If I'm using it as a remote terminal, then actions will take a long time, if it has a list of commands I want it to flash the command it is currently doing so I have a sense of progress, I don't want to stall the CPU for this blink that will add more time to the already slow process. Hardware blinking would have been a crucial feature of the hardware.
Things I would like to change
C64 I want Cart without KERNAL banked in thanks.
C128 that people loved it and understood it more in its time so we got much better software and games.
C64 and C128 the VIC arranges the sprites X and Ys as
X 0,1,2,3,4,5,6,7
Y 0,1,2,3,4,5,6,7
not X0,Y0,X1,Y1,X2,Y2,X3,Y3,X4,Y4,X5,Y5,X6,Y6,X7,Y7
Amiga would be sweet if it had the Lynx Blitter sprites engine.
SNES an extra bit for sprite tile address and drop a priority bit or something else.
NES so many flaws it would be a whole new machine by the time I was done with it
However for control software I 100% want a blink. If this computer is controlling a machine and there is an error or warning, I want that screen blinking.. without slowdown, without some random software bug stalling the CPU causing it not to blink. That is how Nuclear power stations melt down.
If I'm using it as a remote terminal, then actions will take a long time, if it has a list of commands I want it to flash the command it is currently doing so I have a sense of progress, I don't want to stall the CPU for this blink that will add more time to the already slow process. Hardware blinking would have been a crucial feature of the hardware.
Things I would like to change
C64 I want Cart without KERNAL banked in thanks.
C128 that people loved it and understood it more in its time so we got much better software and games.
C64 and C128 the VIC arranges the sprites X and Ys as
X 0,1,2,3,4,5,6,7
Y 0,1,2,3,4,5,6,7
not X0,Y0,X1,Y1,X2,Y2,X3,Y3,X4,Y4,X5,Y5,X6,Y6,X7,Y7
Amiga would be sweet if it had the Lynx Blitter sprites engine.
SNES an extra bit for sprite tile address and drop a priority bit or something else.
NES so many flaws it would be a whole new machine by the time I was done with it
Re: What is one thing about a retro console/computer's specifcations that you would change?
The Atari 7800 could have been a lot better if it had it's own audio chip. Supposedly they wanted to, but Atari told them no. So the designers instead decided the chip would be go in the cartridge. Apparently this chip "Minnie" existed as a prototype, but was never put into production. Some original documents were shared from the designers of it recently (2021), linked from here.
http://7800.8bitdev.org/index.php/The_7 ... sound_chip
One unusual thing with this chip, allows two custom waveforms in ROM, 64 * 8 bits, they expected to change it with different game releases.
Would have been hilarious if Colecovision had survived long enough to use Famiclone chips in an official expansion module.
http://7800.8bitdev.org/index.php/The_7 ... sound_chip
One unusual thing with this chip, allows two custom waveforms in ROM, 64 * 8 bits, they expected to change it with different game releases.
Would have been hilarious if Colecovision had survived long enough to use Famiclone chips in an official expansion module.
- Individualised
- Posts: 310
- Joined: Mon Sep 05, 2022 6:46 am
Re: What is one thing about a retro console/computer's specifcations that you would change?
The GameCube should have used full-size DVDs instead of mini DVDs. My guess as to why they used mini-DVDs was to compete with the Dreamcast's GD-ROM, this would make sense as GameCube is thought to have started early development around late 1998 or early 1999. However, the PlayStation 2 and Xbox ended up using full-sized DVDs, putting the GameCube at a major disadvantage, and I guess by the time the PS2 was released the GameCube was too far along in development to make such a change. Using full-sized DVDs would have only meant a very minor change in the GameCube's form factor, as the top can almost fit one.
The GBA should have allowed you to use the SM83 in GBA mode. The only part of the GBC SoC that it allows you to access in GBA mode is the PSG; it otherwise only serves as backwards compatibility for GBC and DMG games. Because the GBA does not have a dedicated sound chip (except for the PSG of course), most games had to generate their audio in software, which ended up being a sizeable bottleneck, as you had to carefully balance CPU time. Allowing access to the SM83 in GBA mode would allow games to use it as a co-processor for audio generation, alleviating the problem. This would be similar to how most MegaDrive games run their sound driver on the Z80 (which, coincidentally, is a close relative of the SM83.). Doing this however would probably cause an issue for Nintendo; the Gameboy Micro, along with all systems in the DS/3DS line do not contain the SM83 (actually the Micro does, but it's incompatible with legacy cartridges, rendering it unused), only the ARM7, meaning they aren't backwards compatible with DMG and GBC games, only GBA games (the PSG was relocated to a different chip.) Allowing the use of the SM83 in GBA mode would have meant they would be supporting to around 4 generations back by the time the 3DS was released. It would have probably meant that the DS would end up being a new hardware design altogether instead of being a continuation of the GBA architecture.
(Not so sure if I'm right about this one) As far as I'm aware, Game.com games have to run in some sort of layer between the game and the software (though what this exactly comprises of, I'm not so sure). This was probably one of the main reasons why Game.com games were so slow, as it only contains an 8-bit CPU (possibly an SM83, again just like the Gameboy? The Game.com's SoC is called the SM85, but I wasn't able to find conclusive evidence on what CPU core is inside of it. I do remember something from a while back mentioning the SM83 though, and it would make sense for Sharp to use it here.) running at 10Mhz, which while is still faster than even the GBC you still probably want full hardware access when writing code for it. Games having access to the bare metal would have probably allowed for much more impressive games on the Game.com. Of course, this would only matter if Tiger allowed third party developers to develop for the system, which they didn't; "third-party" titles had to all be developed in-house by Tiger, including big names like Castlevania Symphony of the Night (unreleased, but close to being finished) and Sonic Jam.
The GBA should have allowed you to use the SM83 in GBA mode. The only part of the GBC SoC that it allows you to access in GBA mode is the PSG; it otherwise only serves as backwards compatibility for GBC and DMG games. Because the GBA does not have a dedicated sound chip (except for the PSG of course), most games had to generate their audio in software, which ended up being a sizeable bottleneck, as you had to carefully balance CPU time. Allowing access to the SM83 in GBA mode would allow games to use it as a co-processor for audio generation, alleviating the problem. This would be similar to how most MegaDrive games run their sound driver on the Z80 (which, coincidentally, is a close relative of the SM83.). Doing this however would probably cause an issue for Nintendo; the Gameboy Micro, along with all systems in the DS/3DS line do not contain the SM83 (actually the Micro does, but it's incompatible with legacy cartridges, rendering it unused), only the ARM7, meaning they aren't backwards compatible with DMG and GBC games, only GBA games (the PSG was relocated to a different chip.) Allowing the use of the SM83 in GBA mode would have meant they would be supporting to around 4 generations back by the time the 3DS was released. It would have probably meant that the DS would end up being a new hardware design altogether instead of being a continuation of the GBA architecture.
(Not so sure if I'm right about this one) As far as I'm aware, Game.com games have to run in some sort of layer between the game and the software (though what this exactly comprises of, I'm not so sure). This was probably one of the main reasons why Game.com games were so slow, as it only contains an 8-bit CPU (possibly an SM83, again just like the Gameboy? The Game.com's SoC is called the SM85, but I wasn't able to find conclusive evidence on what CPU core is inside of it. I do remember something from a while back mentioning the SM83 though, and it would make sense for Sharp to use it here.) running at 10Mhz, which while is still faster than even the GBC you still probably want full hardware access when writing code for it. Games having access to the bare metal would have probably allowed for much more impressive games on the Game.com. Of course, this would only matter if Tiger allowed third party developers to develop for the system, which they didn't; "third-party" titles had to all be developed in-house by Tiger, including big names like Castlevania Symphony of the Night (unreleased, but close to being finished) and Sonic Jam.
Are the documents complete enough to allow the creation of some sort of emulation of the chip? Would have loved to hear how it sounds. It's almost like a poor man's SID but with waveform capabilities.Memblers wrote: ↑Sat Dec 10, 2022 6:21 pm The Atari 7800 could have been a lot better if it had it's own audio chip. Supposedly they wanted to, but Atari told them no. So the designers instead decided the chip would be go in the cartridge. Apparently this chip "Minnie" existed as a prototype, but was never put into production. Some original documents were shared from the designers of it recently (2021), linked from here.
http://7800.8bitdev.org/index.php/The_7 ... sound_chip
One unusual thing with this chip, allows two custom waveforms in ROM, 64 * 8 bits, they expected to change it with different game releases.
Would have been hilarious if Colecovision had survived long enough to use Famiclone chips in an official expansion module.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: What is one thing about a retro console/computer's specifcations that you would change?
No it was to combat piracy. Given the CD-ROM got burners it was only a matter of time before DVD burners were released and opened the door to massive piracy ala PS1. The Mini discs used by the Game Cube were not able to be pirated. Eventually the tops of the GC were modified so you could fit a full size dvd onto it and mod chips allowed you to read them. But it did make it a lot harder for the average person to do it.Individualised wrote: ↑Sat Dec 10, 2022 7:05 pm The GameCube should have used full-size DVDs instead of mini DVDs. My guess as to why they used mini-DVDs was to compete with the Dreamcast's GD-ROM, this would make sense as GameCube is thought to have started early development around late 1998 or early 1999. However, the PlayStation 2 and Xbox ended up using full-sized DVDs, putting the GameCube at a major disadvantage, and I guess by the time the PS2 was released the GameCube was too far along in development to make such a change. Using full-sized DVDs would have only meant a very minor change in the GameCube's form factor, as the top can almost fit one.
Yeah and battery life.The GBA should have allowed you to use the SM83 in GBA mode. The only part of the GBC SoC that it allows you to access in GBA mode is the PSG; it otherwise only serves as backwards compatibility for GBC and DMG games. Because the GBA does not have a dedicated sound chip (except for the PSG of course), most games had to generate their audio in software, which ended up being a sizeable bottleneck, as you had to carefully balance CPU time. Allowing access to the SM83 in GBA mode would allow games to use it as a co-processor for audio generation, alleviating the problem. This would be similar to how most MegaDrive games run their sound driver on the Z80 (which, coincidentally, is a close relative of the SM83.). Doing this however would probably cause an issue for Nintendo; the Gameboy Micro, along with all systems in the DS/3DS line do not contain the SM83 (actually the Micro does, but it's incompatible with legacy cartridges, rendering it unused), only the ARM7, meaning they aren't backwards compatible with DMG and GBC games, only GBA games (the PSG was relocated to a different chip.) Allowing the use of the SM83 in GBA mode would have meant they would be supporting to around 4 generations back by the time the 3DS was released. It would have probably meant that the DS would end up being a new hardware design altogether instead of being a continuation of the GBA architecture.
I found the data sheet on Sharp's web site by googling the chip part number. Looked different to to the SM83 but that could just be because Sharp don't use Z80 menomics and have their own.(Not so sure if I'm right about this one) As far as I'm aware, Game.com games have to run in some sort of layer between the game and the software (though what this exactly comprises of, I'm not so sure). This was probably one of the main reasons why Game.com games were so slow, as it only contains an 8-bit CPU (possibly an SM83, again just like the Gameboy? The Game.com's SoC is called the SM85, but I wasn't able to find conclusive evidence on what CPU core is inside of it. I do remember something from a while back mentioning the SM83 though, and it would make sense for Sharp to use it here.) running at 10Mhz, which while is still faster than even the GBC you still probably want full hardware access when writing code for it. Games having access to the bare metal would have probably allowed for much more impressive games on the Game.com. Of course, this would only matter if Tiger allowed third party developers to develop for the system, which they didn't; "third-party" titles had to all be developed in-house by Tiger, including big names like Castlevania Symphony of the Night (unreleased, but close to being finished) and Sonic Jam.
Re: What is one thing about a retro console/computer's specifcations that you would change?
What's missing is the details on the LFSR, no word on the length, or tap bits. That part would be have to be guessed at. Another interesting feature there is that it allows mixing noise in with the other waveforms. You can adjust the level of noise used as phase modulation, indexing the waveform.Individualised wrote: ↑Sat Dec 10, 2022 7:05 pm Are the documents complete enough to allow the creation of some sort of emulation of the chip? Would have loved to hear how it sounds. It's almost like a poor man's SID but with waveform capabilities.
I saw someone on AtariAge say they wanted to try supporting it on of the POKEY replacement boards. Hopefully that can work.
Re: What is one thing about a retro console/computer's specifcations that you would change?
The GC mini-discs were indeed for avoiding piracy, but it didn't require modding the case and using normal dvds. Mini-dvds were widely available and normal dvd burners could burn them, so just a modchip was necessary. The mini-dvds were slightly more expensive per disc than normal ones, so cheap people did cut their cases, but it wasn't the common option. My cube is chipped, and I used mini-dvds back in the day. Nowadays not worth the bother of course, using a Wii with the softmod works easier.
I disagree the space limit made any big difference. Most PS2 titles did not use the full size, and much of the size on the big ones was FMVs anyway which could be easily scaled. Lack of ports was mostly just Nintendo being Nintendo, limits, costs, harder to program for.
I disagree the space limit made any big difference. Most PS2 titles did not use the full size, and much of the size on the big ones was FMVs anyway which could be easily scaled. Lack of ports was mostly just Nintendo being Nintendo, limits, costs, harder to program for.
- Individualised
- Posts: 310
- Joined: Mon Sep 05, 2022 6:46 am
Re: What is one thing about a retro console/computer's specifcations that you would change?
Are you sure about this? Blank mini-DVDs exist and can fit in most PC DVD drives. The GameCube used a special copy protection on its disc (which also doubled as a way to make it legally distinct from DVD to avoid paying licences; but other than the copy protection they are pretty much standard DVD and some older PC drives can even read them), and the Wii used the exact same thing, but with full-sized DVDs.Oziphantom wrote: ↑Sat Dec 10, 2022 10:16 pmNo it was to combat piracy. Given the CD-ROM got burners it was only a matter of time before DVD burners were released and opened the door to massive piracy ala PS1. The Mini discs used by the Game Cube were not able to be pirated. Eventually the tops of the GC were modified so you could fit a full size dvd onto it and mod chips allowed you to read them. But it did make it a lot harder for the average person to do it.Individualised wrote: ↑Sat Dec 10, 2022 7:05 pm The GameCube should have used full-size DVDs instead of mini DVDs. My guess as to why they used mini-DVDs was to compete with the Dreamcast's GD-ROM, this would make sense as GameCube is thought to have started early development around late 1998 or early 1999. However, the PlayStation 2 and Xbox ended up using full-sized DVDs, putting the GameCube at a major disadvantage, and I guess by the time the PS2 was released the GameCube was too far along in development to make such a change. Using full-sized DVDs would have only meant a very minor change in the GameCube's form factor, as the top can almost fit one.