What I meant is that the logic required is just two or three simple logic operations. CE is the command execute bit, already there, they would just have had to tie it up with the IRQ (interrupt request) line and a new enable bit (“EN3”). So it would’ve been a very simple and cheap feature to add, almost a no-brainer.
Oh, now I got it.
Interrupt on command completion is in the V9990 too, but nevertheless it would’ve been trivial to add to the V9938 (just CE OR /EN3 AND /IRQ), so it’s a shame it isn’t there.
Eh, oh. Well... The problem is not only in the interrupt availability. It is also about the "PRECISE INTERRUPTS", or its absence. Atari 2600, NES, SNES, all use precise interrupts.
Why? Because 6502 is a poor man RISC processor with Von Neumann bus interface. Interrupt entry is well timed, so, can be synced with the raster.
No precise interrupts - add copper, like in Atari 800XL or Amiga, which can wait on raster and load the registers when necessary.
If there are no precise interrupts and no copper - the reloadable graphics context is doomed. And a simple parallax scrolling is also doomed, and re-loadable sprites doomed and the context palette switching is doomed too.
As discussed in many threads, V9938 was a silicon prototype and obsolete device when came out. Actually, expressing more precisely, from the pure IC design standpoint it was a design marvel , but from the architectural point of view - a retro tech. How many ICs could incorporate a high performance RGB palette DAC those days? In 1985 - none! But 9938 had it all.
The HW architecture was obsolete, but good enough for the office applications, tutoring and home entertainment.
IMHO, what saved MSX2 is a magnificent BASIC implementation, which used every single feature of the VDP. I remember, that to code a simple demo on Amiga with reloadable palette, I had to read Amiga Hardware Reference Manual for about a couple of months just to code a dozen lines in ASM. And on MSX2 - you write something and bingo, you've got it all in minutes!
So, after all have they (ASCII + Microsoft + etc) managed to build an MSX2 as the great gaming console - NO? But as the school computer - IMHO, they have done a great job. Simple and clean hardware, simple but well documented software. Even MSX bus timing was documented from the start. The first ISA spec with the timing came out only in 1987.
How many other platforms we know with the same expendability and the documentation level? Hmmm, not that many.... actually very few. Amiga Zorro and Apple NuBus comes to my mind.
Was it any better @ Commodore or Atari? AGA chipset was the disaster in many ways, which actually killed the beauty of Amiga, IMHO.
So every story has its rise and fall.
Also an interesting fact - MSX platform had a very good attachement rate of modern peripherals. Video editing, professional music creation etc.
Bottom line:
Can I complain - no.
Can the things be done better - yes, certainly.
Also we know, that right at the end, R800 had incorporated the necessary modifications. And there was the speed, lots of it, but also that was the end. And for me TR is not the last machine in a row, but the beginning of the new story which never happened.
It has always baffled me that they designed an extendable home computer system without also providing a uniform way to find and identify these extensions.
Instead, everybody has to do some manual exhaustive slot selection search trying to find a 'unique enough' string of bytes somewhere in a cartridge's ROM to identify it. Extremely fragile and poorly thought out.
And for me TR is not the last machine in a row, but the beginning of the new story which never happened.
As sad as it can be, I think that Turbo R is more a FLUSH of a beginning of the new MSX story that failed to see the dawn of a new day. I think that's clear that Turbo R is an INCOMPLETE machine. I can clearly see the absence of the "new VDP" (no matter if it was the V9990 as we know or something integrated to the existing V9958 features) and of a DMA controller. I can live peacefully with the idea of the Turbo R being an hybrid machine, a chimera that combined the MSX2+ and something else completely different and completely so compatible with legacy MSX, but all the other features (VDP with dual-ported RAM, PCM Audio, Audio digitizer (yes, that microphone input), DMA transfer capable FDC, everything screams DMA (eat this: According to Turbo R GT service manual, while MSX-ENGINE's BUSACK and BUSRQ signals are pulled up, R800 BUSAK and BUSRQ signals are still connected to S1990!). Who knows?
Why? Because 6502 is a poor man RISC processor with Von Neumann bus interface.
......
As discussed in many threads, V9938 was a silicon prototype and obsolete device when came out.
1) Maxis do you think they have in mind the v9958 when they released v9938?
should be interesting to find some evidence on v9938 that prove that v9938 is something like a BETA v9958.
2)please do not call 6502 a RISC processor. RISC mean reduced instruction set computing. Reduced not in the number of available opcodes, rather in complexity of the opcode itself. And i cannot consider a pre/post indexed addressing operation a kind of simple opcode. from this perspective it's more RISC the z80 that 6502.
the maximum we had was a ld reg,(ix+2) ;-)
6502 is a low cost cpu, stackptr of 8 bit for example.
only 3 registers A, X, Y, zero page memory oriented cpu.
I don't think there's something to be called RISC on 6502, but we have to agree that this little beast is more cycle efficient then almost everything sold in late 70's and early 80's... That's why people are so comfortable calling it RISC.
Why? Because 6502 is a poor man RISC processor with Von Neumann bus interface.
......
As discussed in many threads, V9938 was a silicon prototype and obsolete device when came out.
1) Maxis do you think they have in mind the v9958 when they released v9938?
should be interesting to find some evidence on v9938 that prove that v9938 is something like a BETA v9958.
2)please do not call 6502 a RISC processor. RISC mean reduced instruction set computing. Reduced not in the number of available opcodes, rather in complexity of the opcode itself. And i cannot consider a pre/post indexed addressing operation a kind of simple opcode. from this perspective it's more RISC the z80 that 6502.
the maximum we had was a ld reg,(ix+2) ;-)
6502 is a low cost cpu, stackptr of 8 bit for example.
only 3 registers A, X, Y, zero page memory oriented cpu.
1. Yes, by looking at the VRAM timings (time slot access reservation) I can only say that either Yamaha wanted to reduce the number of the silicon pre-prototypes by integrating and not using some features in V9938 and "flight proove" the next generation, or the V9938 design project was running very late and the only option of making it on-time was to cut some features at the last moment. Hence - no time to cost/performance-optimize the design, which is a common design phase, which comes after the silicon prototype validation.
2. When we define the RISC to the students we give the clear case example, which is Standford MIPS processor.
ARM which stands for Acorn RISC Machines, has also post-indexed and pre-indexed modes close to 6502. Also ARM including ARM7TDMI doesn't exploit the Harward archicture either. And ARM is still the RISC processor. Why? Because the main criteria of being a RISC or CISC is having or not the PLA instead of the microinstruction sequencer. So, the definition of the RISC in the industry is not such a clear case and actually more related to its implementation or microarchitecture.
The presence of PLA revolutionized the 6502 based computers and allowed to interleave the CPU bus access with the graphics/DMA bus access without slowing down the latter. Hence, 6502 is a poor man RISC.
Z80 couldn't provide the same. Hence - separate video RAM was the performance improvement decision. The well known attempt to combine the fast CPU access and memory mapped video buffer as we know was made by Sinclair Research in their Spectrum 48K. Spectrum 48K has 2 memories: fast RAM for the CPU only and slow RAM for the shared VIDEO DMA + CPU access. And the bus management is solved by ..... 8 resistors and one TTL chip. Brilliant, but this is an analog rather than digital solution.
For the others -> the separate VRAM became the main choice. Also we remember, that MSX1 was a very successful computer having no custom chips specifically made for MSX. So, the choices were limited.
Sorry for the offtop
Complaints? The price of used game carts!
Not really a complaint but more of a wish - A MegaFlashROM with 512k, SCC+, SD and FM Pac, the all in one solution - it seems an obvious thing to make so why has nobody done it yet?
Not really because at that time the TMS is released with only 4KB of VRAM because the Ram was very expensive.
in 1983 ram was not so expensive. most msx'es have 32 or 64Kb of DRAM. VRAM was 16Kb.
So the TMS vdp in 1983 was a obsolete chip.
The presence of PLA revolutionized the 6502 based computers and allowed to interleave the CPU bus access with the graphics/DMA bus access without slowing down the latter. Hence, 6502 is a poor man RISC.
Umh, graphics where easy to integrate due to the simple memory access pattern on 6502. For example, the z80 had a more complex memory access pattern and timing. on 6502 the first period of cycle is always available. So one can use for any operation.z80 also have variable len cycles+ the built in refresh cycle.
The well known attempt to combine the fast CPU access and memory mapped video buffer as we know was made by Sinclair Research in their Spectrum 48K. Spectrum 48K has 2 memories: fast RAM for the CPU only and slow RAM for the shared VIDEO DMA + CPU access. And the bus management is solved by ..... 8 resistors and one TTL chip. Brilliant, but this is an analog rather than digital solution.
to me it looks like a low cost solution rather than brilliant. ;-) . As is the "cut the clock to cpu" instead of use CPU lines
for a more complex synchronization like BUSXX or WAIT signals.
But it worked, well. And more importantly no contention on "fast" ram. ;-) by contrast the 6502 cpu-based C64 always incurred on penalities from VIC-II expecially on "bad lines" or full sprite-loaded scanlines. in the worst case the cpu can be stopped for 64us. (a scanline)
Also amstrad CPC proved to successfully sync the z80 with video hw that was memory mapped.
would be nice to calculate for all those micros how in average was the drop % of speed compared to uncontended access.
Later a question. Do you think it's possible to interface a VIC-II chip with a z80 based computer without loosing too much on cpu side?