Konix Multi-System articles

And now - emulated!

[video=youtube_share;EJbB10Z-6fo]http://youtu.be/EJbB10Z-6fo[/video]

Lee has put in a heck of a lot of work to make this happen, the Bios from a later version of the prototype system was found and implemented (a challenge in it's self), the disk image was created from a low level (the lowest possible magnetic flux variations) using Kryo flux. The image was interpreted - again, not easy as it's a propriety format with some copy protection, and then all the additional work required to implement the differences between this slightly later version of the Devkit to the ones we've been exposed to already. Floppy handling routines, graphics handling, audio and controls all needed working out above and beyond what had already been done.

So - not just a walk in the (central) park... (sorry, I never tire of trying to make that funny).

 

Fantastic work. So looking forward to be able to play a Konix in the future. Well, visit emulation that is.

 

It's great to see more stuff coming out of the woodwork for the Konix still. I remember reading about it as a kid and thinking it sounded awesome.

Amazingly, the games still look pretty decent!

 

While searching for some old magazines online, i came across these:

https://issuu.com/zetmoon/docs/ace_issue_18_1989_mar

https://issuu.com/zetmoon/docs/thegamesmachine16

 

Funny, I went to visit my sister and saw that she is keeping my brother's gamepad that uses those plastic molds, I remembered this thread right away.

 

- I just discovered about this through a different forum
- Downloaded the emulator and the assembler+source code
- to my huge surprise, both ran just fine!
- I verified the build was deployed by changing some text string - see the attachment


Now, this doesn't seem to have the DSP assembler, which is obviously the source of majority of POWAH in the system. When I checked the old docs, I noticed some very cool features of the Blitter that the Jaguar doesn't have, and which would be very beneficial for the 3D flatshading (which is something I am quite experienced with on jaguar, and recently also on 6502), most notably a list of scanlines forming the polygon, that would greatly accelerate the flatshading. Of course, 25 MIPS and parallel processing from DSP is another killer feature, since this is 50% more I get on jaguar !

That being said, Jeff's source code has some DSP code in hexa that's being uploaded and run on DSP, so this is an alternative plan:
- Using the compiler codebase I wrote during last decade, I can write my own DSP assembler, probably over a weekend, just by tweaking my VRBasic compiler.
- All I need is more documentation on DSP's hexa opcodes
- My DSP assembler would then simply output the hexa opcodes into text file
- This hexa DSP file would be uploaded at runtime through 80x86 code


Of course, there's still coding fun to be had even at this stage - since we have a completely working game here, one can experiment with Blitter being run from 80x86, but I'd be really intrigued in testing the system's real polygonal throughput, considering I have a 3D engine running on an ancestor of this puppy (jaguar's GPU+Blitter).

I also firmly believe, that this is something the people who invested blood, sweat and tears few decades ago, would love to see.

 

- I have streamlined the build&deploy scripts, so that while I'm in Notepad++, I just hit F5 and get an executable built that is then automatically forwarded to the emulator, so it's now very quick to do some experiments
- I realized this particular emu is geared towards the very first Konix (e.g. 8086), hence we can only use 128 KB as RAM
- while this may not seem like a big deal, a 256-color framebuffer 256x200 takes 50 KB. Double-buffering takes 100 KB, hence leaving only 28 KB for the rest
- 28 KB would be nothing for bitmap games, but 3d flatshading is doable, as 3D mesh definition takes very little space

- I'm still hoping that eventually I figure out if it's possible to use the RAM area <$0000 - $40000> for the framebuffers, as it's flagged as Internal screen RAM (hence it's questionable at the moment and quick glance at Jeff's code didn't reveal it with definite conclusion). If not, 28 KB it is

- Even if I was driving Blitter just from 8086, according to the docs, the Blitter has 9.2 MB / s available system bandwidth (after the screen buffer is read). 9.2 / 60 = 157 KB / frame (at 60 fps). At 4-bit color resolution (where whole framebuffer takes up 25 KB), this means that even after clearing whole screen, you still have ~130 KB worth of Blitter bandwidth and 84% of frame time is still available. At 60 fps, none the less !
- This is actually faster than on Atari Jaguar ! I sure wish I had 84% of frame time available after I clear it !
- Now, if you take into account the fact that Konix's Blitter can actually process a list of commands, it's quite a beast, especially in flatshading department
- I started experimenting with Blitter yesterday, and hope I can soon get its killer feature implemented
- I believe this thing could actually run something like my jaguar's StunRunner dataset at 20-30 fps, even using just the 8086, thanks to the Blitter

 

Ah, You're here too! Well - I'm looking forward to seeing if DASM works so that you can build DSP code

 

Took me one evening to debug through all the interrupts that Jeff was using (instead of timer code) for basically everything, but eventually I managed to get a blank screen without any camel nonsense putzing around

Took another evening to figure out which asm instructions actually work and which don't (e.g. forget mul/div etc.), as the assembler was indeed built to support only instructions and addressing modes that Jeff was using



This is the fourth assembler I've been using in last 2 weeks (6502:Atari 800, 68000:Jaguar, GPU Risc:Jaguar, 8088:Konix), but I still believe I'm sane



Tonight, I took the liberty of adapting the dataset from Atari 800 and few stages of the 3D pipeline. This is a reference rasterizer (drawing pixels just on CPU) that will assist in troubleshooting Blitter rasterizer.



What I really would like to get to, eventually, is the Sequencer stage of the Blitter. I can't believe they had this feature in '88, but removed it for jag ! You could, in 1988, create a list of blitter commands and then just let Blitter crunch through it (without the interrupts on jag). Granted, 8088 becomes halted, but the DSP continues to run in parallel. In 1988 ! Stunning !



Another thing: The Blitter has available bandwidth of 9.2 MB/s. In 16-color mode that means that there's 160 KB worth of bandwidth per frame (at 60 fps). But clearing that screen takes just 25 KB of those 160. So, one still has about 85% of frame time available. I sure wish I had that on jag.



Clearly, even without DSP, this thing could have 20-30 fps flatshaded games, as at 6 MHz, the 8088 can easily prepare the command list for Blitter in 1-1.5 frame, and Blitter would take less than half frame to render it.

With DSP's 12-25 MIPS, and parallel execution, 60 fps (for simple/moderate 3d scenes), easy.



It's extremely unfortunate, from technological perspective, this beast didn't get a chance to catch on...



I love coding on jaguar, but this is just another level, given the 1988...





To me, this is equivalent of NASA's Moon Landing. Some day I would love to meet Flare guys... ***RESPECT.GIF***