What is one thing about a retro console/computer's specifcations that you would change?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

User avatar
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?

Post by Individualised »

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.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: What is one thing about a retro console/computer's specifcations that you would change?

Post by dougeff »

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.
nesdoug.com -- blog/tutorial on programming for the NES
Catyak
Posts: 54
Joined: Mon Apr 25, 2022 4:33 pm

Re: What is one thing about a retro console/computer's specifcations that you would change?

Post by Catyak »

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.
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.
User avatar
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?

Post by Individualised »

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.
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).
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: What is one thing about a retro console/computer's specifcations that you would change?

Post by lidnariq »

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.
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.

Separately, I think the "blink" attribute dates to previous monochrome displays.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: What is one thing about a retro console/computer's specifcations that you would change?

Post by Dwedit »

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!
Joe
Posts: 650
Joined: Mon Apr 01, 2013 11:17 pm

Re: What is one thing about a retro console/computer's specifcations that you would change?

Post by Joe »

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.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: What is one thing about a retro console/computer's specifcations that you would change?

Post by zzo38 »

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.
(Free Hero Mesh - FOSS puzzle game engine)
Oziphantom
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?

Post by Oziphantom »

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 ;)
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: What is one thing about a retro console/computer's specifcations that you would change?

Post by Memblers »

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.
User avatar
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?

Post by Individualised »

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.
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.
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.
Oziphantom
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?

Post by Oziphantom »

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.
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.
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.
Yeah and battery life.
(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.
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.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: What is one thing about a retro console/computer's specifcations that you would change?

Post by Memblers »

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.
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.

I saw someone on AtariAge say they wanted to try supporting it on of the POKEY replacement boards. Hopefully that can work.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: What is one thing about a retro console/computer's specifcations that you would change?

Post by calima »

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.
User avatar
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?

Post by Individualised »

Oziphantom wrote: Sat Dec 10, 2022 10:16 pm
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.
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.
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.
Post Reply