Impressive that you read all 33 pages! I have not reviewed the thread in a long time, so I hope it was at least interesting. :-)
I do plan to make the HDL open source, I'm just not sure of the time-frame on that. I'm also going to release the PCB and such, but there is really nothing special about it. The board is just the minimum required to support the FPGA, a resistor DAC for video, a level shifter for the I/O to the host computer, serial flash, oscillator, power regulators, and headers.
Yes, everythiing got really interesting. I'm amazed how the TI99 scene manages to do great things. I tried to get one many years ago, but there were some problems and these weren't shipped to me (long story).
This device would manage to add true VGA output to many retro systems.
And if you someday get motivated to it, please consider add support for successors of the 9918A VDP. But it would be even better if you make a team behind this project to make it growing
- The Memotech MTX range of home computers is lesser known, but those features a Z80 microprocessor, a TMS9929 video chip (same as the MSX1 video chip except different color encoding output) and also the same audio processor as used in the Sega and ColecoVision.
Graphics: VDP (Video Display Processor) derived from Texas Instruments TMS9918
- 32 simultaneous colors available (two separate palettes with 16 colors out of 64)
- Screen resolutions 256×192 and 256×224. PAL also supports 256×240
- 3.546893 MHz for PAL/B/G (through 4-pin DIP crystal oscillator)
- 3.579545 MHz for NTSC (clock provided by MSX)
- 3.575611 MHz for PAL-M (by replacing the 4-pin DIP oscillator, not included)
- 8×8 pixel characters, max 463
- 8×8 or 8×16 pixel sprites, max 64
- Horizontal, vertical, and partial screen scrolling
"The Sega VDP is for a large part TMS9919 compatible."
Texas Instruments' TMS9918A was succeeded by Yamaha's Yamaha V9938, which added additional bitmap modes, more colorful sprites, a vertical scroll register and a customizable palette. The V9938 was used in a third-party upgrade to the TI-99/4A — the Geneve 9640 'computer-on-a-card'.
The V9938, in turn, was succeeded by the Yamaha V9958, which added some additional high-color modes and a horizontal scroll register. These chips were used in the "TIM" upgrade card for the TI-99/4A, as well as on the MSX 2 and MSX 2+/turboR systems, although rumor has it that the V9958 was also used in a generation of the Photo Play arcades. Yamaha also produced a Yamaha V9990, which is considered the follow-up of the V9958 by some, but it is not backwards compatible. A graphic chip extension utilizing the V9990 exists for the MSX in the form of the 'Graphics9000' cartridge by Sunrise.
Correction: "amused reply". Apologies if this wasn't apparent.
The incident should serve as a timely reminder of the perils of hair-trigger cinematography when the resulting vignettes are primarily used to draw attention to the perceived shortcomings of other people's software, especially when the shortcomings later turn out to be in one's own software; shortcomings apparently overlooked while the UI is augmented with translucent windows and other such visual niceties. Nothing wrong with bugs: the very best authors write software with bugs in them, and I have no objection to a descriptive bug report when a cinematic featurette is not absolutely required. I have no wish to impede the narrative flow of the Aspeqt monologue; I merely point out that it shouldn't have taken FJC's could-hardly-hold-the-camera-steady-for-laughing reply to instigate the troubleshooting procedure you describe in the second paragraph of post 672. This procedure is best carried out prior to unfolding the director's chair, since otherwise, the diagnosis of issues in the "official" build of Aspeqt becomes circumstantially dependent on FJC's deadpan, pragmatic response. This means that were it not for FJC's response, the latest bug in Aspeqt might not have been discovered, and the alarming upshot of this is that I have been an unwitting instrument in the "testing programme" of Aspeqt - an application I no longer use in its latest incarnations, and have no desire to test.
In short, there are less convoluted, non-cinematic ways to discover bugs: namely, the awkward business of testing. Only then can we attain the prized goal of "Solid software".
I'm just a stalker here, but I would like to reply about your message.
Why do you use this kind of response? Why are you so much strong opinionated? If you have something against the author or the way of making software, then keep use the software you prefer or make your own (I cannot find one in atari8.co.uk).
Why do you write in that redundant and literary-like way? I appreciate your skills at the English language, something it's quite difficult to me as I'm not native English and my formal education was quite crappy, but I don't understand why the same message can't be written in a simpler form.
It seems you feel upset about someone saying your software was buggy, because you're too proud on it. Why people can't fail? And if the current AspeQt developer failed in the way of dealing the problem, he can now understand his wrong ways. People can learn from it's errors.
Personally, I would prefer a more universal program like AspeQt but for 8/16bit systems (both consoles and computers). I was an uCON64 user in the past and had a MDPRO from ToToTeK, I miss that kind of software integration. But I consider AspeQt quite useful, despite I'm more of a keyboard junkie (so I would prefer a ncurses frontend). But this doesn't make me to hate AspeQt or not wanting to use it.