F18A

[matthew180]

Originally my goal was to keep the design inside the 40-pin 600mil package (the size of the original 9918A), but 4-layer boards with parts on both sides, 003/003mil trace/spacing, fine-pitch BGA packages, and 0102 SMD parts were beyond what I was willing to pay for or even able to assemble myself.

 

Overall though, it is pretty small and I have not really had any problems in any of the systems I have tried it in, other than having to squash down some of the disc capacitors that some boards (CV) use for the DRAM chips.

[Tursi]

Hehe.. Sometime's list reminded me there's at least two arcade machines that use it, too.. Baby PacMan and Cliff Hanger (though Cliff Hanger uses it for video overlay, so the F18 won't do the trick there, unless you want to add that too! )

 

Heh, more analogue electronics... not this time. If I sell a million units then I'll retire and work on the external video input.

 

hehe!! Actually, in theory (and from observation of the feature on the real 9918A many years ago), I think it's just an analog switch. The video input is switched on and off by the VDP register control bit. When it's off, the VDP behaves normally. When it's on, I believe two things happen:

 

-First, for any pixel that renders to the screen as transparent, the external video is switched through to the output

-Second, the VDP horizontal and vertical counters are synchronized to the external video via the SYNC pin (although this part I don't fully understand offhand - there are interesting voltages going on with the real 9918A IIRC).

 

The VDP still generates the blanking and sync signals, the video "overlay" seems pretty simple (external video on/off on a per-pixel basis), it's just locking to the external sync that is a little tricky.

 

Anyway, that's technically off-topic music, I think. Sorry about that!

[kl99]

Wonderful news Matthew! Looking forward to meet you on the upcoming Chicago Faire!

 

I am no way an engineer and have only limited technical skills, nonetheless would like to bring in these questions:

 

Will the F18A be compatible with the MBX device for the TI-99? It's basically only input/output communicating with the TI-99 but as it once was meant to be a stand alone computer could there be any technical issues, that makes the system incompatible to use with F18A equipped TIs?

 

If the VDP replacement uses lower power couldn't there be a power overload somewhere else in the system as a result? I mean that another chip gets too much voltage as a result?

 

What is the current status on the 80column mode? You talked about it in this thread but as far as I know, there is no word yet whether it's part of the present features or not.

 

Is the V1.0/1.1/1.2 featuring VGA 640x480 or SVGA 800x600?

 

Do the boards feature Software Updatability?

 

You talked about a FPGA TMS9900 CPU replacement sometime, maybe happening by you. What advantages do you see, that go beyond the original features/specs? I know by far too few about the system. Is it addressing issues? Is it timing? Maybe you can talk a little to give us non-pros a view what might be possible...

 

Do you see a point in FPGAs replacing the sound chip and the speech chip?

 

Please see this posting with deepest respect in your talent and hard work within your free time, not as a wishlist nor complaints.

 

Klaus

[matthew180]

Will the F18A be compatible with the MBX device for the TI-99? It's basically only input/output communicating with the TI-99 but as it once was meant to be a stand alone computer could there be any technical issues, that makes the system incompatible to use with F18A equipped TIs?

 

The F18A will not interfere with any other part of the system, 3rd party hardware, etc. The only problems the F18A may introduce would be software problems due to me screwing up some part of the design.

 

If the VDP replacement uses lower power couldn't there be a power overload somewhere else in the system as a result? I mean that another chip gets too much voltage as a result?

 

No. Electronics do not work that way. A device, like a chip, only draws as much *current* as it needs. As for voltage, the 99/4A's power supply regulates the voltages (+5V, +12, and -5V in this case.) A very basic example would be, say you have 10 chips that require 5V and 100mA (milliamps) each. Your power supply needs to be rated at 5V, 1A (amp) to power those 10 chips. Actually, you better double the power supply rating since you do not want to run you power supply at 100%. If you drop your design to 8 chips, now you only need a power supply rated for 5V, 800mA, so your original 1A power supply will be fine and only run at about 80% of max. Just because you removed two chips from your design does NOT mean the extra 200mA have to go in to the other chips.

 

What is the current status on the 80column mode? You talked about it in this thread but as far as I know, there is no word yet whether it's part of the present features or not.

 

Non existent. I'm not sure yet how I want to do this. I *really* don't like the 9938, it makes a huge mess of everything and the design is extremely complicated. Some of it has to do with keeping compatibility with the 9918A, and the rest is just doing things because they could. I may still try to put in enough of the 9938's registers to support setting its 80-column mode, but we'll see. The biggest problem currently is that the FPGA does not have enough on-board RAM to support a full 9938 implementation, and adding an external SRAM would have made the board design too big and power-hungry. If I do implement the 80-column mode, it would only work with software that sets up all the tables in the original lower 16K RAM area.

 

Is the V1.0/1.1/1.2 featuring VGA 640x480 or SVGA 800x600?

 

The versions are more related to hardware board changes than software. I suppose I should be calling the board changes "revisions". At this point it is just for my benefit so I know what board I am about to solder chips on to.

 

Currently the F18A drives the VGA monitor at 640x480@60Hz. I chose 640x480 for a few reasons:

 

1. Every VGA monitor made since the late 1980's supports that resolution

 

2. 256 doubles (each 9918A pixel is two VGA pixels) to 512, which fits in the 640 with a nice border that simulates the borders on a 9918A monitor

 

3. If I do implement 9938 modes, the 512 pixel modes will still fit in the same area and just be VGA pixels

 

4. I have more time (higher resolution means more pixels, which means pumping pixels faster)

 

5. A lot of 4:3 aspect flat-panel monitors have a native resolution of 1024x768 or 1280x1024 and scale well to 640x480

 

800x600 posed problems like having to triple the 256 resolution, which gave less of a border. Also, I could not double the 9938's 512 pixel resolution, so in those modes (if I do 9938 modes) you would have a LOT of border. Running even higher resolution, like 1024 or 1280 was just not feasible at this time. Those resolutions require 80MHz+ pixel clocks and don't give much room to scale. For example, if I implemented 1024 and someone was running on a 1280 native flat screen, that resolution will not scale as well as a 640 resolution.

 

Basically I assume most people are going to use a flat panel monitor which have "native resolutions" where things look the best. Real CRT's do not have these problems. Ideally I would be super elite and detect the monitor and it's native resolution and drive it accordingly, but I'm not that elite yet. Making a modern video card is not something I'm trying to do, and probably not possible with a 100MHz 250K-gate FPGA.

 

Do the boards feature Software Updatability?

 

Maybe. Originally, no, not without a USB chip on-board (which the F18A does not have) or the user having a JTAG programmer (most people don't.) However, I may have a solution for that, but I'm still working on it. If I can work it out I will, since that makes my life easier too.

 

 

You talked about a FPGA TMS9900 CPU replacement sometime, maybe happening by you. What advantages do you see, that go beyond the original features/specs? I know by far too few about the system. Is it addressing issues? Is it timing? Maybe you can talk a little to give us non-pros a view what might be possible...

 

I don't think I will be making a pin-compatible replacement for the 9900. For one, it is too big physically, and making these boards that plug in to the original footprint of the original chips really sucks! The 9900 is a giant and would require people to desolder it and fabricate a socket. If I do a 9900, it will be part of a SoC (system on a chip), and that system will probably be a 99/4A.

 

Advantages over the real chip are numerous. The read-before-write can be removed, the registers can be brought in to the CPU instead of being in RAM, the execution speed can be increased without affecting system timing, new instructions and registers can be added (like a stack pointer with push and pop instructions), the address space can be increased, etc.

 

Do you see a point in FPGAs replacing the sound chip and the speech chip?

 

Speech? No. I think a speech chip is beyond my mathematical ability to comprehend right now. Speech is complicated, hard to program for, takes a ton of system resources (RAM and CPU) to process, and not used very much. IMO speech is a novelty.

 

As for sound, yes, sound chips are not too difficult to do in an FPGA. However, replacing the sound chip in the 99/4A would require another pin-compatible device, or something to plug in to the existing board with a cable back to a main board with the FPGA on it. I don't see this happening in the 99/4A. More feasible would be adding a sound module to the F18A and providing a new audio output. But I'm not sure anyone would program for it since it is possible not everyone will have an F18A, and that seems to be a big deal to everyone writing software these days.

[+retroclouds]

Back to the F18A. I'm a hardware noob. So how is outputting sound gonna work?

Ofcourse the F18A will not be involved in that.

My guess is you will need an extra cable for that? If yes, where to get it?

I think that's an important issue that might perhaps scare off some people that know nothing about hardware ?

 

Wouldn't wanna end up having a crystal clear picture with no sound at all

[+retroclouds]

As for the F18A advanced features, thinking 80 column mode. Why not work out some kind of (software) design specification together with the

Colecovision (ADAM) and MSX1 folks. Ofcourse this feature would not be compatible with the V9938, but I think it might cool if a

home computer brand independant feature could be done.

 

Here's another question. Would it be possible to address more than 16KB VRAM memory in a future design?

 

This guy is apparently using 32K of VRAM

 

http://www.youtube.com/watch?v=gm7rovR5ih4

[Tursi]

Hehe.. that's a fantastic port of Asteroids for our little chip.

 

The concept of bankswitching the 9918 VRAM is simple enough, it would just be coming up with a way to do it and getting that adopted as standard. From my quick look at the 9938 datasheet, it looks like the higher memory access is a bit of a pain?

[matthew180]

Back to the F18A. I'm a hardware noob. So how is outputting sound gonna work?

Ofcourse the F18A will not be involved in that.

My guess is you will need an extra cable for that? If yes, where to get it?

I think that's an important issue that might perhaps scare off some people that know nothing about hardware ?

 

Wouldn't wanna end up having a crystal clear picture with no sound at all

 

Sound will still come from the 5-pin DIN connector on the back of the 99/4A. If you currently have the composite monitor cable, then you can still use that to run the audio to an external speaker (since you would not be using the speaker in your TV or monitor any more.)

 

As an option, I could probably include an extra RCA jack that could pick up the audio and bring it to the back of the 99/4A, but you would have to be handy with a soldering iron to make the two necessary connections. For ColecoVision users, this will not be an option (the audio on the CV is part of the RF output signal which will go dead), since they will have to be removing the 9928/9 and adding a socket anyway.

[matthew180]

As for the F18A advanced features, thinking 80 column mode. Why not work out some kind of (software) design specification together with the

Colecovision (ADAM) and MSX1 folks. Ofcourse this feature would not be compatible with the V9938, but I think it might cool if a

home computer brand independant feature could be done.

 

I thought about that, but something new and not currently supported would probably not go over very well. I'll probably stick with the 9938-way of doing things.

 

Here's another question. Would it be possible to address more than 16KB VRAM memory in a future design?

 

This guy is apparently using 32K of VRAM

 

I can't figure out what that guy is doing with 32K of VRAM. He can bank-switch it out from under the 9918A, but he would have to have most of the data set up the same in both banks, otherwise your display would go crazy when you switched. I can't find any real details on his site about how he is using the 32K VRAM.

 

If / when I do more than the initial 16K, I will most likely do it the 9938-way.

[matthew180]

The concept of bankswitching the 9918 VRAM is simple enough, it would just be coming up with a way to do it and getting that adopted as standard. From my quick look at the 9938 datasheet, it looks like the higher memory access is a bit of a pain?

 

The 9938 can support 192K of VRAM. First they extend the 9918A's address register from 14-bits to 17-bits, which gives them 128K, then they have an "expansion RAM" which bank-switches the lower 64K. The bank switching is controlled by a bit in one of the new registers introduced by the 9938, and I think some of the internal "commands" can perform their operations between the "expansion RAM" and video RAM automatically. There is a pin (4) called *VDS that is controlled by the bank-switching bit, and is used to select the alternate DRAM chips (I think).

[kl99]

Thanks for the detailed reply on my questions Matthew.

 

Regarding the 80 columns card: system-99 user-group (snug) from germany created two video cards for the PEB of the TI-99 in their past:

http://home.arcor.de/system-ninety-nine-user-group/evpc/index_e.htm

 

Maybe that helps you designing around the 9938.

 

Klaus

[+Yurkie]

It's been awhile any updates?

[matthew180]

I finally resolved the ColecoVision problems, and accidentally fixed an MSX problem that I didn't know even existed! I'm up to revision 1.3 and I just got the boards about a week or so ago and I'm building about 5 of them for some final testing. If I don't run in to any issues, these will probably be the ones that go in to production. Lots of learning going on, painful learning, learning the hard way. Why does it always have to be the hard way?

 

For some reason I decided to also add composite output. Granted it will be gray-scale if it happens at all, but it might be there. So, you would have VGA output *and* the original composite. We'll see though, it has been a pain in the ass and sometimes I wonder "what the hell am I doing???"

 

I posted an update on my site about making the boards: http://codehackcreate.com/archives/279

 

I'm not done with that "story" yet, but that is the start of it. Might help someone avoid some of my screw ups.

[matthew180]

I've added some initial support for 80-columns and it works with Mark Wills' Forth! I also have had limited success with MSX BASIC. The main problem for complete support is that the 9938 has four "ports" to communicate with the host CPU, and the 9918A only has two. So, any configuration done via those extra ports can not be supported via a 9918A socket. Anyway, it seems to be working and there will be support for 80-columns, depending on how the code is written.

 

Image 1 is Forth in 80 columns, set up by simply typing: 2 GMODE

Image 2 is MSX BASIC being forced in to 80 columns, but thinking it is still in 40 column mode.

[+acadiel]

Nice, Matthew! I'm anxiously awaiting getting my hands on one of these!

 

Jon

[+OLD CS1]

Nice, Matthew! I'm anxiously awaiting getting my hands on one of these!

 

Jon

 

SECOND.

[Willsy]

I think I just pee'd in my pants a little. Yep.

 

I WANT ONE OF THESE NOW!!

[Willsy]

Matthew

 

If you want something more interesting on the screen, type this in:

: CSET 2 GMODE  8 0 DO  256 0 DO I EMIT LOOP  LOOP ;

 

Then just type CSET and press enter

[+retroclouds]

Matthew

 

If you want something more interesting on the screen, type this in:

: CSET 2 GMODE  8 0 DO  256 0 DO I EMIT LOOP  LOOP ;

 

Then just type CSET and press enter

 

Just tried it, but all I get is a blank screen. Am I doing something wrong?

 

EDIT: I tried this in classic99. Do I need some kind of 80 columns device?

Edited August 8, 2011 by retroclouds

[Willsy]

Matthew

 

If you want something more interesting on the screen, type this in:

: CSET 2 GMODE  8 0 DO  256 0 DO I EMIT LOOP  LOOP ;

 

Then just type CSET and press enter

 

Just tried it, but all I get is a blank screen. Am I doing something wrong?

 

EDIT: I tried this in classic99. Do I need some kind of 80 columns device?

 

 

Classic99 doesn't support 80 column mode at the moment. Fred Kaal's emulator does, and there is a version of a TurboForth available for it on the the TurboForth website.

 

As an aside, Fred's emulator also emulates the other hardware functions on the 9938 such as hardware line draw and rectangles etc.

[matthew180]

Willsy: Cool! I was trying to get some code to dump something to the screen, but could not figure out anything, and after 30 minutes of flailing at 2am, I gave up.

 

Retroclouds: Nope, Tursi has not incorporated any 3398 support yet. We have talked a bit about how much support he might add, since Classic99 will have to deal with similar issues I'm having to address with the F18A. I'm not sure of his time frame or how much support he might add, but adding the 80-column text mode was not too big of a deal for me since I kind of planned for it.

 

Here are some more images: the code Willsy just gave me, and the latest F18A in the 99/4A with the case-mod for the VGA connector.

[discomeats]

I came here as this thread was linked from the blog. I see a lot of the obvious ideas for features have already been stated, I haven't read through the whole thread so sorry if I repeat or offend anyone

 

Aside from the obvious scrolling and the maintaining of the 4th sprite/sprite collision stuff optionally (which some things rely on one way or another) some suggestions:

 

- per line sprite colouring

- dual playfields with as appropriate flexible sprite priority

- using pattern data for sprites

- sprite x/y flipping (don't think there's enough room in 16k for another table of pattern attributes (x/y/priority/opacity?/etc) unless using pattern data as sprites)

- raster interrupts - which will also help greatly with sprite multiplexing/raster effects

- multiple palette sets fg-playfield/bg-playfield/sprites (or doing something slightly crazy with colour values so that instead of directly refering to pairs of 16 colours they instead refer to a table of 256 palette pairs which could display 512 colours directly on screen without trickery (this is something that's been bouncing about in my head for making a colourful 2bitplane display)

- sprite chaining

- vram write address modulo increment - greatly speed up writing to vram for horizontal scrolling

- row/column edge blanking - so that it doesn't look naughty around the edges while writing new name table data while scrolling

- if you want crazy suggestion add sprite scaling too

 

Anyway, hopefully this doesn't look too idiotic for suggestions.

[matthew180]

Thanks for the post! :-)

 

Let me try to address some of these. The main problem with adding functionality that does not exist in any current chip (9918A, 9938, etc.) is that no one will already know how to use the features, and no existing software will take advantage of it. Basically it makes the effort hard to justify since the realistic amount of new software is pretty slim. I'm not totally sure which features you mention that might exist in the 9938/58 though.

 

- per line sprite colouring

 

Does this exist in the 9938/58? This is not really that hard to do, but if the functionality does not exist then I have to invent the method, which means no one will use it.

 

- dual playfields with as appropriate flexible sprite priority

 

Define "playfield", exactly. I'm not sure what that means.

 

- using pattern data for sprites

 

You can do that already. Just point the sprite pattern table to the same location as the tile patterns. Or do you mean "in addition" to the tile patterns? The problem is, the sprite "name" is a single byte, which limits you to 256 possible patterns. To have more "names" for a sprite you have to reinvent the sprite attribute table, or pick up another bit somewhere, which would double the names.

 

- sprite x/y flipping (don't think there's enough room in 16k for another table of pattern attributes (x/y/priority/opacity?/etc) unless using pattern data as sprites)

 

There are a few unused bits in the sprite attribute table, and I was planning on adding *at least* X/Y flip.

 

- raster interrupts - which will also help greatly with sprite multiplexing/raster effects

 

The problem is, there is no facility to receive this interrupt on most systems other than mixing it with the current vertical interrupt. Which means you would have to do a lot of checking in software to determine which interrupt was sent. While easy to do on the FPGA, it is hard to manage on the host computer and would mess up any existing software. Probably the best thing to do would be to have an internal GPU that can execute certain commands based on the current scan line. Kind of like the Amiga's copper.

 

- multiple palette sets fg-playfield/bg-playfield/sprites (or doing something slightly crazy with colour values so that instead of directly refering to pairs of 16 colours they instead refer to a table of 256 palette pairs which could display 512 colours directly on screen without trickery (this is something that's been bouncing about in my head for making a colourful 2bitplane display)

 

I have a few ideas for more colors. Again the problem is current support and inventing the way things are laid out. Lack of availability makes it hard to justify. But I'm willing to be swayed.

 

- sprite chaining

 

Thought about that one a long time ago. Can you give me your "technical" explanation of what it means to you?

 

- vram write address modulo increment - greatly speed up writing to vram for horizontal scrolling

 

Yup, that one is already in the works! You can thank the NES for that idea. :-) I just recently read the specs (what little there is) on the NES and it looks like the ripped the 9918A off big time! I'm surprised TI did not sue Nintendo.

 

- row/column edge blanking - so that it doesn't look naughty around the edges while writing new name table data while scrolling

 

This one is new to me, can you elaborate?

 

- if you want crazy suggestion add sprite scaling too

 

Other than magnify? Can you provide (or point me to) an algorithm that can be implemented in hardware, somewhat easily?

 

Unfortunately, any changes to the sprites pretty much means doing them totally differently. Kind of like the 9938/58 has the "sprite 2" mode. Backward compatibility in hardware is much harder than in software.

[discomeats]

heh, you did ask for suggestions.. ok, I fail at quoting so here goes

 

 

- per line sprite colouring - Does this exist in the 9938/58? This is not really that hard to do, but if the functionality does not exist then I have to invent the method, which means no one will use it.

 

9938/9958 feature, which works with the dual sprite palette value OR mode to enable multicolour sprites - look at the aleste series on the MSX2 to see it working particularly effectively.

 

- dual playfields with as appropriate flexible sprite priority Define "playfield", exactly. I'm not sure what that means.

 

an alternate term might be layers, instead of having just "sprites on top of a image" you might have sprites + a forground layer and background layer, the megadrive/genesis has a "window layer" (for overlaying game info like score/liveswhatever) + forground and background layers + sprites (which can be prioritized to be above or below each layer). in the colour modes of the 9918 there's enough memory for two complete name tables, now on a standard vdp this could be helpful for doing double buffered graphics, but if both name tables were used at once - one layered on top of the other you'd have dual playfields. you could of course achieve a similar effect by using two or more VDP's using the builtin overlay features of the vdp. To see the effect of doing this with the 9958 have a look at the MSX VSU (which someone on here already mentioned) on youtube and pretty much every 2d arcade machine with scrolling graphics.

 

 

Quick and dirty mockup

 

 

- using pattern data for sprites - You can do that already. Just point the sprite pattern table to the same location as the tile patterns. Or do you mean "in addition" to the tile patterns? The problem is, the sprite "name" is a single byte, which limits you to 256 possible patterns. To have more "names" for a sprite you have to reinvent the sprite attribute table, or pick up another bit somewhere, which would double the names.

 

I mean in the same way as using pattern data for patterns using the pattern table + the colour table at the same time it'd be more of a vdp reg setting to enable this, instead of just picking up the 1 plane sprite data as normal, 256 patters (or sets of patterns) is still quite a lot, plenty games just repeat the same 256 patterns 3 times for the whole screen to make writing to the name table consistent. One could also select in the vdp regs which of the 3 sets of 256 patterns to use.

 

To give a visual idea, we currently do 1, we'd be able to do 2 (using 2nd sprite for the engine flame here) which is impossible on the 9918 and uses only 2 sprites.

 

 

Giving the same freedom in graphics for sprites as ordinary graphics but with the bonus of using them like sprites.

 

 

- sprite x/y flipping (don't think there's enough room in 16k for another table of pattern attributes (x/y/priority/opacity?/etc) unless using pattern data as sprites) - There are a few unused bits in the sprite attribute table, and I was planning on adding *at least* X/Y flip.

 

I can't remember off the top of my head if the 9938 uses some of those bits, but as some suggestions go beyond the 9938 anyway I guess it's moot.

 

- raster interrupts - which will also help greatly with sprite multiplexing/raster effects - The problem is, there is no facility to receive this interrupt on most systems other than mixing it with the current vertical interrupt. Which means you would have to do a lot of checking in software to determine which interrupt was sent. While easy to do on the FPGA, it is hard to manage on the host computer and would mess up any existing software. Probably the best thing to do would be to have an internal GPU that can execute certain commands based on the current scan line. Kind of like the Amiga's copper.

 

the vdp status bit has room in it, to show if this is a vblank or a raster interrupt 5th sprite/collision etc.

 

- multiple palette sets fg-playfield/bg-playfield/sprites (or doing something slightly crazy with colour values so that instead of directly refering to pairs of 16 colours they instead refer to a table of 256 palette pairs which could display 512 colours directly on screen without trickery (this is something that's been bouncing about in my head for making a colourful 2bitplane display)

 

I have a few ideas for more colors. Again the problem is current support and inventing the way things are laid out. Lack of availability makes it hard to justify. But I'm willing to be swayed.

 

More colours is purty

 

- sprite chaining

 

Thought about that one a long time ago. Can you give me your "technical" explanation of what it means to you?

 

I'd hardly call it technical explanation you update the location of one sprite and any sprites attached to that move in concert with that sprite, instead of writing multiple sprite data you'd have a first sprite and next sprites would be linked to it with an x/y offset this way you could control an "arbitrarily" sized sprite as a single one. In some systems, sprite chaining means something else. Sprites really are a whole magic world unto themselves I think with a bit of research you'll find all kinds of crazy stuff.

 

- vram write address modulo increment - greatly speed up writing to vram for horizontal scrolling

 

Yup, that one is already in the works! You can thank the NES for that idea. :-) I just recently read the specs (what little there is) on the NES and it looks like the ripped the 9918A off big time! I'm surprised TI did not sue Nintendo.

 

- row/column edge blanking - so that it doesn't look naughty around the edges while writing new name table data while scrolling

 

This one is new to me, can you elaborate?

 

if you have 32 visible display columns, and 32 columns of memory, everything looks great when it's static, but when it's scrolling you have to write data into where your new column appears, this means that while the image scrolls at the borders you'll occasionally see the next graphic to scroll into the screen just appear as it's written.

This is a feature of the 9958, "blank left 8 pixels to bordercolour" so that everything can be changed without visual poop. I think the C64 also has this feature In that it can blank the outermost rows and columns to the bordercolour.

 

- if you want crazy suggestion add sprite scaling too

 

Other than magnify? Can you provide (or point me to) an algorithm that can be implemented in hardware, somewhat easily? - Unfortunately, any changes to the sprites pretty much means doing them totally differently. Kind of like the 9938/58 has the "sprite 2" mode. Backward compatibility in hardware is much harder than in software.

 

I did say it was crazy

 

Whenever I've asked about how the arcade machines did this in the 80's I get the answer "they used tables" and then silence and I've never been given a good explanation of it.

 

The simplest method I can imagine boils down to manipulating a reference pointer to a stream of graphical data which depending on desired screen location/magnification starts with knowing what pixel of the graphic to start displaying (as some of it may already be off screen ) and then repeatedly outputting the same pixel for the appropriate number of iterations before moving onto the next one in the case of magnification. For shrinking, output a pixel and then skip "n pixels" along to the next appropriate pixel to output, in both cases repeat until there's no more pixels or you run out of screen width. For no size adjustment, just display pixel, move to next. This is something that can translate to just incrementing a memory pointer (though for bitplane graphics I guess there's a bit more pointer fu but you get the idea), the fun part is knowing where to init the pointer, and when to increment it and by what value. Maybe that's where the "tables" come in. It also means that magnification isn't a special case of sprite display, it's just something inherent to sprites. I don't know if it'd be necessary to keep a line buffer for each magnified sprite for repeat/skipping for the Y lines of the sprite. I pulled this technique out of the top of my head and I've no idea how the clever folks did it in days of yore but this seems reasonable to me for the simplest method.

 

Well, I hope that didn't all come off as complete blithering idiocy, and I have no doubt that folk could come up with a lot more suggestions too. Of course, it's only worthwhile if people take advantage of them but your project is interesting in itself as a general purpose plug in VGA graphic system that could have uses outside of ye retro systems.

 

I do appreciate that not everything might be reasonably feasible, but the more ideas that get thrown at something the more that some of them will stick. All this sort of stuff is a lot easier when you have huge frame buffers, near instant blitting and many GHz isn't it

 

And for a 2nd post this ended up ridiculously epic and is no doubt full of sanity errors so I'd better go for a lie down now

[matthew180]

Thanks for the explanations, I'm pretty clear now on all the features you were talking about. I'll see what I can do and what makes sense. Some stuff is obviously easier than others, and a few I think are too advanced for the 99/4A.

 

but your project is interesting in itself as a general purpose plug in VGA graphic system that could have uses outside of ye retro systems.

 

I have definitely given that some thought too! The 99/4A hobby market is not as big as we would all like it to be, so any means to expand the potential user base makes things more feasible, and in some cases possible.

 

All this sort of stuff is a lot easier when you have huge frame buffers, near instant blitting and many GHz isn't it

 

Yes, yes it is. And many people have the perception that just because their modern PC has something, or that the collective "we" have had such technology for years and years, that is should be a simple thing to add. People forget that it took years of iterative development and knowledge to create the stuff we have today, or even chips that came a few years later (like the 9938/59, 9990, etc.) However, as a hardware developer, I'm just starting out and I don't have the luxury of a team of electrical engineers and mathematicians to help work out the design, or years of making graphic hardware.

 

It is easy to get lost in a feature list; I did when I started working out the features I originally wanted to include, and almost none of those features are in the design today.