F18A

[Tursi]

I don't know, I'm still on the fence about calling an SoC "emulation". In software there are tons for different ways to do the same thing, and you don't have true parallelism (beyond two threads running on a dual-core CPU.) In hardware you really don't have many options for address decoding, clock distribution, multiplexing, pipelines, etc. It is all done the same way, with the same chips and flip-flops. The set of tools is smaller and more defined, thus you end up with very similar solutions for the same problem. I would argue that a block diagram of the F18A would look pretty close to the one in the data manual.

 

Great. But the documentation doesn't cover the low level internals of how features were implemented, and problems occur in clones when software takes advantage of how something actually works versus how it's documented to work.

 

Your paragraph here, though, is exactly the point that I was trying to make, that someone people start questioning the terminology. But the terminology doesn't matter. In the end, you aren't using the original hardware, and there is a good chance of variances. Your chip already differs greatly from the 9918 - for example, the way you handle sprites is completely different (even ignoring the lack of flicker, you don't build up a table of sprites to draw on the next scanline).

 

I'm not saying there is anything WRONG with this, and there's no need to defend your work, it's fantastic. I was stating WHY I didn't want to make a TI SOAC when this first came up years ago.

 

Well, in hardware, if your timing is wrong then the circuit simply will not work. It *all* comes down to timing, as I have learned over and over with the FPGA.

 

That's too general a statement to be true. If you build a full SOAC, you don't need to reproduce any of the original system's timing. You can have zero-wait-state GROM (one of your stated goals!), VDPs that don't have propagation delay from CPU to VRAM (you've already achieved this), hell, you don't even need to use a four phase CPU clock (why would you? )

 

If you were doing a "real" clone with various chips, you would be using the same core parts, 9900, 9901, etc. and there are only so many ways you can hook up those chips and still make them work. Using your argument, you could say that the 32K-in-the-console "modification" somehow makes the computer no longer a 99/4A, but a clone.

 

No, you're putting words in my mouth now. I'm talking about a SOAC. If I put your FPGA 9918 in my TI, it's still a TI to me. If you release a full SOAC TI, that's a clone. I don't think anyone would disagree about that.

 

I'm going to just stop here.

[matthew180]

Great. But the documentation doesn't cover the low level internals of how features were implemented, and problems occur in clones when software takes advantage of how something actually works versus how it's documented to work.

 

Well, in this case I do have some internal notes produced by the 9918A designers, and in the block diagram when it shows a "shift registers", there aren't too many different ways to do a shift register in hardware. I guess that's the main point I was making. In software you would not implement sprites like that, but in hardware it becomes the logical conclusion.

 

In the end, you aren't using the original hardware, and there is a good chance of variances. Your chip already differs greatly from the 9918 - for example, the way you handle sprites is completely different (even ignoring the lack of flicker, you don't build up a table of sprites to draw on the next scanline).

 

Of course there will be variances, but that does not mean 100% original functionality cannot be achieved. I'm actually not doing my sprites too differently than the original hardware (but we hardly had time to talk about it at the Faire...) I don't build a list of sprites to draw on the next scan line because I implemented 32 sprite shift registers instead of just four. I think the original 9918A would have done more sprites if they could have squeezed in more shift registers. Also, like the original, I read the sprite data during the current scan line to display on the next scan line, with the only difference being I have enough time to read the data for all 32 sprites instead of just 4. So yes, from that standpoint it is different, but only in the speed and density. I would argue that my shift registers and sprite FSM are pretty close to the original.

 

I'm not saying there is anything WRONG with this, and there's no need to defend your work, it's fantastic. I was stating WHY I didn't want to make a TI SOAC when this first came up years ago.

 

I think you're reading me wrong. I'm not trying to be defensive, we're just discussing our points of view, which historically between you and me has always been different. Personally I think that is good and has forced me to look at some things in different ways.

 

Well, in hardware, if your timing is wrong then the circuit simply will not work. It *all* comes down to timing, as I have learned over and over with the FPGA.

 

That's too general a statement to be true. If you build a full SOAC, you don't need to reproduce any of the original system's timing. You can have zero-wait-state GROM (one of your stated goals!), VDPs that don't have propagation delay from CPU to VRAM (you've already achieved this), hell, you don't even need to use a four phase CPU clock (why would you? )

 

Those things are true, however, the timing between when the CPU pulls the CSR or CSW inputs low and the time the VDP responds must be *exactly* right or the CPU would not be able to get data in or out of the VDP. That is more of the timing I'm talking about, but even internally to the FPGA timing has proven to be the cause of probably 95% of all my problems.

 

If you were doing a "real" clone with various chips, you would be using the same core parts, 9900, 9901, etc. and there are only so many ways you can hook up those chips and still make them work. Using your argument, you could say that the 32K-in-the-console "modification" somehow makes the computer no longer a 99/4A, but a clone.

 

No, you're putting words in my mouth now. I'm talking about a SOAC. If I put your FPGA 9918 in my TI, it's still a TI to me. If you release a full SOAC TI, that's a clone. I don't think anyone would disagree about that.

 

My apologizes, I'm not trying to put words in your mouth.

 

So at what point does it stop being a 99/4A and start being a clone? You say the F18A in a 99/4A is still a 99/4A. So what if I do the 9900 on a board with and FPGA. Then the 9901, sound chip, etc. until I have just the motherboard with all the original chips removed and replaced with FPGAs. At what point did the computer cease to be a 99/4A?

 

This is really a philosophical question at that point and has been argued in just about every aspect of human existence. At what point does a pile of sand become a desert? If I could replace parts of my brain with artificial replacements (talking hypothetical future medical stuff here), at what point to I stop being me?

 

Personally I think the system can be reproduced perfectly (from a technical standpoint) in an FPGA, but whether or not that reproduction is a 99/4A can only be answered by each individual.

 

I'm going to just stop here.

 

I'm not trying to ruffle your feathers mate, just having a discussion.

 

I think it comes down to each person's feelings and interpretation of these words:

 

* Simulator

 

* Emulator

 

* Reproduction

 

To me they differ in the "level" each goes to. Classic99 claims to be an emulator, Win994a states it is a simulator. The primary difference being that a simulator will reproduce the results using any means available, which in software indicates the guts of the simulator would probably have little to nothing to do with the way the machine actually operates.

 

An emulator is attempting to follow the way the actual hardware works to provide an environment for the software to run.

 

A reproduction (FPGA, SoC) are the physical hardware equivalent of an emulator, with the primary difference being the medium used, ie. physical flip-flops vs. software, which makes the difference substantial.

 

When you can't tell the difference between the real thing and the simulator, emulator, or reproduction, then to me it is the same as the real thing. If you were to run Classic99 under DOS, ie. the only program running on the CPU, then you could probably achieve emulation such that you can't tell the difference. However, as it stands now, the OS will always get in your way, the sound will be a little off, there will be video glitches, etc. that are out of your control. Using real hardware does not suffer these problems, and to me that is the difference.

 

I love Classic99 and I'm very glad you wrote it and continue to work on it! And if you did a version that you distributed on floppy or CD that could boot a computer and be the only program running on the CPU, then we would have our SoC...

 

Matthew

Edited November 30, 2010 by matthew180

[Tursi]

Well, in this case I do have some internal notes produced by the 9918A designers, and in the block diagram when it shows a "shift registers", there aren't too many different ways to do a shift register in hardware. I guess that's the main point I was making. In software you would not implement sprites like that, but in hardware it becomes the logical conclusion.

 

First, I'm a little distressed that you are taking my personal reasons for not working on a TI SOAC MYSELF as some kind of an attack on your project. I only addressed your comment that you expected someone else to have done it already with my thoughts on the concept - it was something I was involved in discussing at length years ago. Hell, you gave me my FPGA education.

 

And yeah, you have a lot of notes. But the F18A is still not a 100% reproduction of the TMS9918A - I already noted some of your deliberate changes. To think that you will have no accidental changes is a little surprising to me - nothing is ever perfect. Some we may not even see for a long time yet!

 

Of course there will be variances, but that does not mean 100% original functionality cannot be achieved.

 

If you know and can test 100% of the functionality. I don't know 100% of the functionality of the 9918A. You are claiming to? And you have ways to test all of it?

 

I'm not going to sit and argue with you about it. I just find it highly unlikely that it will cover everything 100% the first time. It's why I have tried to chip in with the more esoteric parts of the chip that I am personally aware of whenenver I can.

 

Also, like the original, I read the sprite data during the current scan line to display on the next scan line, with the only difference being I have enough time to read the data for all 32 sprites instead of just 4. So yes, from that standpoint it is different, but only in the speed and density. I would argue that my shift registers and sprite FSM are pretty close to the original.

 

You can argue that, but it becomes a strange argument:

 

Me: There are differences between the original chip and yours.

You: My chip is almost the same!

 

It doesn't actually counter my point.

 

I'm not saying there is anything WRONG with this, and there's no need to defend your work, it's fantastic. I was stating WHY I didn't want to make a TI SOAC when this first came up years ago.

 

I think you're reading me wrong. I'm not trying to be defensive, we're just discussing our points of view, which historically between you and me has always been different. Personally I think that is good and has forced me to look at some things in different ways.

 

hmm. I'm glad you clarified this. In truth this discussion is bothering me a great deal and I was about to drop out of it and apologize for ever speaking up at all. We do see things differently but we seem to be arguing semantics right now and it feels kind of pointless.

 

Those things are true, however, the timing between when the CPU pulls the CSR or CSW inputs low and the time the VDP responds must be *exactly* right or the CPU would not be able to get data in or out of the VDP. That is more of the timing I'm talking about, but even internally to the FPGA timing has proven to be the cause of probably 95% of all my problems.

 

You're dealing with a part that is crazy-important on timing, of course - it's the video system and it has no way to indicate being ready to the rest of the machine. Conversely, my GROM work has no such requirements -- I can run at any speed I like and it still works fine, because GROMs completely control the timing (it was great watching the 4A run at 25% speed when I had a full serial debug stream coming out of the chip ).

 

This part of the discussion has actually had me considering this a challenge -- whether I can get a 9918A up and running, in SOFTWARE, on an Atmel. I haven't done the math yet but it seems feasible. As you note though, the memory access timing will be crucially important. (Also the fact that the biggest Atmel I have handy only has 4k RAM will make it hard to boot the console ).

 

So at what point does it stop being a 99/4A and start being a clone? You say the F18A in a 99/4A is still a 99/4A. So what if I do the 9900 on a board with and FPGA. Then the 9901, sound chip, etc. until I have just the motherboard with all the original chips removed and replaced with FPGAs. At what point did the computer cease to be a 99/4A?

 

That's a question that dates back to Plato (ha ha )... I don't know! I think it's a pretty subjective thing. I would probably argue that the video chip replacement has 20 years of proof that people still consider it a TI with a different VDP installed, since we've had a couple of those already. But I can escape from that question sideways by repeating that I've never been discussing piecemeal part replacement.

 

This is really a philosophical question at that point and has been argued in just about every aspect of human existence. At what point does a pile of sand become a desert? If I could replace parts of my brain with artificial replacements (talking hypothetical future medical stuff here), at what point to I stop being me?

 

hehe... and you say the same thing here, I didn't read ahead.

 

Personally I think the system can be reproduced perfectly (from a technical standpoint) in an FPGA, but whether or not that reproduction is a 99/4A can only be answered by each individual.

 

My point is that it can be only if you know every point that needs reproduction. And I don't believe any human knows that. You might run perfectly on every piece of software today only to have something released tommorrow that uses something nobody knew about before. Doesn't mean you shouldn't try, only that you shouldn't be surprised if it happens. Hell, a year ago nobody had ever documented the true timings from the CPU to the VDP, or knew that sprite collisions could be detected mid-screen.

 

The Atari 2600 community only worked out a way to glitch the video chip and force it to produce interlace video about two years ago. You can bet that none of the emulators or FPGA projects supported that glitch until after it was documented. (I always hoped we'd find something similar.)

 

Did I ever mention I finally figured out what was going on in crashes that cause the VDP to lose video sync? I thought it was some weird bug that we might take advantage of, but sadly it was actually very obvious. The external video input control was being turned on.

 

A reproduction (FPGA, SoC) are the physical hardware equivalent of an emulator, with the primary difference being the medium used, ie. physical flip-flops vs. software, which makes the difference substantial.

 

(emphasis mine) Isn't that the same as what I said in the first message that caused all the fuss?

 

When you can't tell the difference between the real thing and the simulator, emulator, or reproduction, then to me it is the same as the real thing. If you were to run Classic99 under DOS, ie. the only program running on the CPU, then you could probably achieve emulation such that you can't tell the difference. However, as it stands now, the OS will always get in your way, the sound will be a little off, there will be video glitches, etc. that are out of your control. Using real hardware does not suffer these problems, and to me that is the difference.

 

It's such a fine line you are describing here that I don't know if it's even worth the debate, and I don't like debating such things anyway. I'd rather discuss facts, theories, experiments and ideas, and not so much what to call something or whether it's worth doing.

 

I love Classic99 and I'm very glad you wrote it and continue to work on it! And if you did a version that you distributed on floppy or CD that could boot a computer and be the only program running on the CPU, then we would have our SoC...

 

Actually the reason I got the Beagleboard was because I was going to port Classic99 to that, see if I could get a small aluminum case, and run it on that. But although I spent the money on it I never got around to starting it - there were more interesting projects to do. I guess technically I came closer to that than the FPGA approach. I was never sure what I was going to do with the FPGA, I would still like to do the external scan-line doubler and video filter, since it's doing the "impossible" (creating a better signal than the input signal by sampling the line, working out the original pixels, and regenerating it).

[kl99]

Hi Matthew!

 

You got a private message from me!

 

And I have two question I want to share:

 

On the TI-99 Mainbyte Page there are two ways described to enhance the visual picture quality:

http://www.mainbyte.com/ti99/display/display.html

http://www.mainbyte.com/ti99/display/display2.html

 

One uses a Resistor Fix, the other a Capacitor Fix.

 

Will the VGA picture Output of the F18A be influenced by these modifications or does F18A bypass these?

 

Sidestory:

My brother has got a console from the international ti-treffen 2009 in vienna, which sure has several modifications in it.

Besides a reset button and a german QWERTZ keyboard the visual output of the machine is way better than all other consoles we tried at the same setup and cables. The color contrast looks like those from the Emulators, in direct comparison the others look like they have washed out colors. The sharpness is very good and text is easily readable.

 

BR, Klaus

[Opry99er]

hey kl99!!! Can you post pictures of that console? =)

[kl99]

hey kl99!!! Can you post pictures of that console? =)

 

Hi Opry99er!

 

check out http://ti99blog.webs.com for a picture, I uploaded for you.

 

BR, Klaus

[+OLD CS1]

hey kl99!!! Can you post pictures of that console? =)

 

Hi Opry99er!

 

check out http://ti99blog.webs.com for a picture, I uploaded for you.

 

BR, Klaus

 

That avatar on your site looks familiar

[Opry99er]

That's a very cool mod!

 

Nice site too... I love reading TI Blogs. If you like TI blogs, find "Tilting at Windmills".... The Realms of Antiquity blog. Un-freaking-real. Adam is a great writer

[matthew180]

First, I'm a little distressed that you are taking my personal reasons for not working on a TI SOAC MYSELF as some kind of an attack on your project. I only addressed your comment that you expected someone else to have done it already with my thoughts on the concept - it was something I was involved in discussing at length years ago. Hell, you gave me my FPGA education.

 

And here we have a perfect example of communication break down due to a text only medium. Here is a beer, I'll have a diet soda, it's all good.

 

I don't think you are, were, or whatever, attacking the project... I'm not sure what gave you that idea. I also never intended to imply that I thought someone (you or whoever) *should have* already done the SoC. I was trying to say that I'm simply really surprised that no one actually has done the SoC. I was sure I would be the last person to get around to doing it, instead of the first.

 

And yeah, you have a lot of notes. But the F18A is still not a 100% reproduction of the TMS9918A - I already noted some of your deliberate changes. To think that you will have no accidental changes is a little surprising to me - nothing is ever perfect. Some we may not even see for a long time yet!

 

I don't think it is perfect yet, but I'll get all the bugs worked out eventually. I never meant to imply that I am, or my work is, flawless - quite the contrary. "Perfect" is subjective, I know nothing, at some level, is ever perfect. I do think I will get it to a point where you can drop it in a 99/4A and run any piece of software ever written for the original 9918A, and have it run the same. Is it there yet? Not sure. It's close. I've run an awful lot of games past the thing, run it on the MSX, played games on the MSX with it, etc. I just a Coleco to test it with - know anyone who has one?

 

Of course there will be variances, but that does not mean 100% original functionality cannot be achieved.

 

If you know and can test 100% of the functionality. I don't know 100% of the functionality of the 9918A. You are claiming to? And you have ways to test all of it?

 

I know 100% of the documented functionality for sure. The internal notes expand some of that information and has helped confirm what is going on inside. The only undocumented (in the datasheet) functionality so far has been the address masking, which was covered in that programmer's document (kind of.) When you are doing hardware and start to implement some of the parts of the system, things start to make sense at a different level than when you are programming. Things that seemed strange, all of a sudden are not so strange. Many times I have said to myself, "ah, so that's why (or how) it does that!"

 

I'm not going to sit and argue with you about it. I just find it highly unlikely that it will cover everything 100% the first time. It's why I have tried to chip in with the more esoteric parts of the chip that I am personally aware of when ever I can.

 

And I appreciate that input greatly! Please don't stop.

 

It doesn't actually counter my point.

 

I'm not always trying to counter your point. Lots of times I come around to your point, and when I start talking in circles I realize I've changed my view.

 

hmm. I'm glad you clarified this. In truth this discussion is bothering me a great deal and I was about to drop out of it and apologize for ever speaking up at all. We do see things differently but we seem to be arguing semantics right now and it feels kind of pointless.

 

Then we stop, and talk about things that aren't pointless. If you are ever reading anything I wrote and start feeling offended, assume it is due to a misunderstand thanks to communicating via text and not talking in person, or something like that. It takes a lot to piss me off or be an ass about something, and it will be pretty obvious if it happens (and never on a public forum, and never to a friend.)

 

You're dealing with a part that is crazy-important on timing, of course - it's the video system and it has no way to indicate being ready to the rest of the machine. Conversely, my GROM work has no such requirements -- I can run at any speed I like and it still works fine, because GROMs completely control the timing (it was great watching the 4A run at 25% speed when I had a full serial debug stream coming out of the chip ).

 

You know, the 9938 added a "ready" output line... Imagine that! It is actually easier to do this in hardware than software. I think about that all the time. My thought process for solving problems is shifting. My devboard has been powered on since the Faire and every time I power up the 99/4A it is plugged in to, it just works. I'm pretty happy with the CPU I/O part anyway.

 

This part of the discussion has actually had me considering this a challenge -- whether I can get a 9918A up and running, in SOFTWARE, on an Atmel. I haven't done the math yet but it seems feasible. As you note though, the memory access timing will be crucially important. (Also the fact that the biggest Atmel I have handy only has 4k RAM will make it hard to boot the console ).

 

Well, you are going to have to be clocking a pretty fast CPU. Like I said above, my thought process is shifting and I don't even know how I would go about doing some of that stuff in software. When the CPU drops the CSR or CSW low, you only have a few microseconds to get the data on the bus. In the FPGA it is easy since things run in true parallel and you don't have to poll an input or respond to an interrupt. The CSR and CSW simply change a flip-flop on the positive edge of the clock, and change the FSM state if either one is low.

 

hehe... and you say the same thing here, I didn't read ahead.

 

See, we agreed on something!

 

Did I ever mention I finally figured out what was going on in crashes that cause the VDP to lose video sync? I thought it was some weird bug that we might take advantage of, but sadly it was actually very obvious. The external video input control was being turned on.

 

Ha, that sucks. By the way, I don't support the external video in, so I guess my reproduction will never be perfect.

 

A reproduction (FPGA, SoC) are the physical hardware equivalent of an emulator, with the primary difference being the medium used, ie. physical flip-flops vs. software, which makes the difference substantial.

 

(emphasis mine) Isn't that the same as what I said in the first message that caused all the fuss?

 

I don't know, I can't remember that far back. Circles, that's all I know.

 

It's such a fine line you are describing here that I don't know if it's even worth the debate, and I don't like debating such things anyway.

 

It is, it's not, me either.

 

Actually the reason I got the Beagleboard was because I was going to port Classic99 to that, see if I could get a small aluminum case, and run it on that. But although I spent the money on it I never got around to starting it - there were more interesting projects to do. I guess technically I came closer to that than the FPGA approach.

 

I remember that. I almost bought one too. Cool little board for sure, but expensive I think, no? $150 anyway if I remember, and I had just bought my FPGA devboard. A software emulator running on dedicated hardware would be *really* nice to have, even if I go as far as making a 99/4A SoC. Just like Classic99, it will always be faster and easier to try things in software first. And if you had a version that would boot a modern PC from CD or Floppy, then we could use any computer as a 99/4A, like a laptop!! *That* would be really cool!

 

Matthew

Edited November 30, 2010 by matthew180

[matthew180]

One uses a Resistor Fix, the other a Capacitor Fix.

 

Will the VGA picture Output of the F18A be influenced by these modifications or does F18A bypass these?

 

The F18A does not use the 99/4A's DRAM (original 16K VRAM), the 10.7MHz video oscillator, the analogue output filter or amplifier circuits, or the 5-pin DIN A/V output. All of that circuitry will pretty much go idle, and no video will be present from the original output connector. The F18A will have a standard 15-pin high density VGA connector for plugging directly into any modern VGA monitor or TV that has VGA input.

 

Matthew

[Tursi]

And here we have a perfect example of communication break down due to a text only medium. Here is a beer, I'll have a diet soda, it's all good.

 

Bleh, I only tolerate beer once a year. And even that's questionable for next year.

 

I'm not sure what gave you that idea.

 

Slightly off topic, but worth dipping into, it was taking my comments about not doing a SoC and replying to them with differing opinions specific to the F18A project. That made it sound as if one was directly related to the other, instead of been more of a mental springboard.

 

I also never intended to imply that I thought someone (you or whoever) *should have* already done the SoC. I was trying to say that I'm simply really surprised that no one actually has done the SoC.

 

Well.. just me, I'm sure, but I think the difference is so slight as to round off to nothing. Also I don't see any problem with thinking someone should have gotten to it by now. It doesn't mean anyone has done anything wrong, just that it was the expectation.

 

I do think I will get it to a point where you can drop it in a 99/4A and run any piece of software ever written for the original 9918A, and have it run the same.

 

Again, not my point. My point would be illustrated by this (hypothetical) series of events:

 

1) You complete your testing and release the device.

2) Someone (me or someone else) discovers that if you flip an unused bit in VDP Register 0 at just the right instant, you get a stable 256-color graphics mode

3) The F18A does not exhibit this glitch

 

It's inevitable, and not really worth a long discussion of, because it's /impossible/ to plan for. But this is the level of detail that I am talking about in my discussions of "differences in implementation".

 

It's got nothing to do with your skill, documentation, or attention to detail.

 

It's also worth noting that the 9918A is such a solidly designed chip that I think the odds of it actually happening are pretty darn low.

 

Is it there yet? Not sure. It's close. I've run an awful lot of games past the thing, run it on the MSX, played games on the MSX with it, etc. I just a Coleco to test it with - know anyone who has one?

 

I got one, hehe. In fact, I want one of your chips for it eventually, because the Coleco has the worst video out of any of my systems.

 

When you are doing hardware and start to implement some of the parts of the system, things start to make sense at a different level than when you are programming. Things that seemed strange, all of a sudden are not so strange. Many times I have said to myself, "ah, so that's why (or how) it does that!"

 

I do /understand/ hardware, I just haven't done very much with it. I've had the same revelation many times working under the hood of Classic99 (which is why when people send me bugs I prefer to test against the real hardware - with the logic probes if needed, to get the RIGHT answer), and I also do hardware troubleshooting at the robot company that I contract with. So yeah, I know where you are coming from. And I also know that the same results can be generated by different circuits, and if you treat those circuits in unexpected ways, they may respond differently.

 

Seriously, when I think about it and try to break it down, all I really mean to be saying is "your chip may behave differently than the original when operated outside of normal parameters."

 

I'm not always trying to counter your point. Lots of times I come around to your point, and when I start talking in circles I realize I've changed my view.

 

Ah, it's my youthful hostility kicking in again. I'll give it a kick and put it back in its cage.

 

You know, the 9938 added a "ready" output line... Imagine that! It is actually easier to do this in hardware than software. I think about that all the time. My thought process for solving problems is shifting. My devboard has been powered on since the Faire and every time I power up the 99/4A it is plugged in to, it just works. I'm pretty happy with the CPU I/O part anyway.

 

I really do think that's bloody awesome, and I'm pretty excited about it. I love the debug switches too.

 

oooh, hey, if you have an extra switch input bit, it might be cool to add the "character set" feature that Classic99 has. When turned on, instead of fetching characters from the SIT, just increment them from 0-255 over and over again.

 

Well, you are going to have to be clocking a pretty fast CPU.

 

I have been thinking about it, and I'm not sure that I will. The default speed of these things is 8MHz anyway, and I can clock it to 20MHz without overclocking. There are VGA cards that run that clock speed.

 

Generating the video is definately possible - people are doing that already. So the question comes down to the CPU access time. When the CPU makes a read request to the VDP, the data has to be on the bus in (you likely know this better than me, but reading Thierry's page it looks like about) 3 clocks (including wait states). So that's 1uS to detect the read request and place data on the bus. (Not to mention having to come OFF the bus in a clock when deasserted). We get 1MIPS per MHZ on the AVR in most code, so at 20MHz that's about 20 instructions. I'd use hardware to shift out the video, so the chip can be in a tight loop watching the CPU most of the time, should be able to respond to a read pulse within 20 instructions. Might get hairy at the end of a scanline though.

 

Might still try this sometime. Definately would need asm, though, it looks like.

 

Like I said above, my thought process is shifting and I don't even know how I would go about doing some of that stuff in software. When the CPU drops the CSR or CSW low, you only have a few microseconds to get the data on the bus.

 

Oh, I know. Don't go thinking I don't know anything about hardware, and I'm just talking out of my ass. I just /like/ software more.

 

Ha, that sucks. By the way, I don't support the external video in, so I guess my reproduction will never be perfect.

 

Yeah, I was thinking about that. Not that I think you should do it, but it's really not too hard. You just have to wait on the external sync pulses to start each part of your output, and use the transparent color as a switch to gate external video out. I played with the external video input of the 9918A many years ago and that's all it does, it doesn't digitize the input signal or anything, it just switches. (Thus the input can be much more hi resolution than the 9918 supports). It was especially clear when I didn't feed external sync into the chip correctly, because in that case when external video was on, the video's sync came through perfectly along with its picture (and the 9918A's image rolled and twisted on top of it).

 

IOW, it doesn't attempt to understand the external video at all. It takes the sync in separately, and just gates the video input as a switch.

 

I remember that. I almost bought one too. Cool little board for sure, but expensive I think, no? $150 anyway if I remember, and I had just bought my FPGA devboard. A software emulator running on dedicated hardware would be *really* nice to have, even if I go as far as making a 99/4A SoC. Just like Classic99, it will always be faster and easier to try things in software first. And if you had a version that would boot a modern PC from CD or Floppy, then we could use any computer as a 99/4A, like a laptop!! *That* would be really cool!

 

I did think of that too, particularly with a laptop, but it's a pretty big hassle. Classic99 is not a portable emulator, it's tied pretty tightly to Windows. Video would not be too hard to replace, especially just using VGA, but the sound card access these days is nasty to do direct, and you'd need to de-thread Classic99 to make the port straightforward (or just write a simple scheduler, I guess).

 

Then I thought, "And how useful would the end result be?" and got, "Not very", and moved on.

 

Some not-useful things I like to do, but that one was too much like work.

[+OLD CS1]

2) Someone (me or someone else) discovers that if you flip an unused bit in VDP Register 0 at just the right instant, you get a stable 256-color graphics mode

 

Can we start this rumor right here, right now? Would make for a good bit of fun. Kinda like the "8MB ChipRAM" jumper on the Amiga 4000 motherboard. That surfaces every so often.

[djpubba]

I just a Coleco to test it with - know anyone who has one?

 

I will send you two ColecoVisions if you send me one back with your chip in it when you're done.

[+5-11under]

I just a Coleco to test it with - know anyone who has one?

 

I will send you two ColecoVisions if you send me one back with your chip in it when you're done.

I'll send three.

[matthew180]

Haha, you guys are killing me. I do need a CV to do initial testing, and since djpubba offered first, I've asked him to send me one.

 

At some point, once I get the boards finished, I will probably be asking for some beta testing in exchange for an F18A, or drastically price reduced anyway (depends on how much the end up costing!) I'm not sure of the "requirements" for beta testing eligibility yet, but for sure those who participate will need to be able to program in assembly language on the respective platform, and promise to write code specifically to test the F18A.

 

But I'm not to that point yet, unfortunately, but I am getting closer and I am spending a lot of time on this right now.

 

Matthew

[matthew180]

5-11under, did you write that Squares program? I should probably follow some of the links in your sig. I wonder if Tursi has his CV programs available somewhere too?

 

I know nothing about the CV, and I really don't want to get distracted looking into it *yet*. I have a board to finish first.

 

Matthew

[Opry99er]

Hey Matthew--- Marc Hull has done some cool work in trying to overrun the VDP on the TI. His theories of shoveling in more DATA into the 9918 than it can process was quite the debate on the OLUG. He wrote a program that created an "arrow" and ran it through a series of color bars in full bitmap mode.... His conclusions are documented in a video on YouTube. Essentially, he came to the conclusion that it can be done, but not by stock gear. Using his 32x16 console, he was able to over-run the VDP. Really cool tests, and I know Tursi was in on the process as well as a couple other 99ers who's names I can't remember.

[matthew180]

Yeah, I was keeping up with the Y! list when Marc posted that. He had his computer at the Faire and I asked him to run that test with my F18A, but being from Oklahoma, he could not remember how to set it up...

 

I'll definitely be looking for someone to try and over run the VDP. It will probably be a tricky test though, since you first have to prove you are over running the real 9918A, then swap to the F18A and have measurable results.

 

I think the MSX1 would be a good platform to test that on, but I don't know any MSX1 assembly programmers...

 

Matthew

[+5-11under]

5-11under, did you write that Squares program? I should probably follow some of the links in your sig. I wonder if Tursi has his CV programs available somewhere too?

 

I know nothing about the CV, and I really don't want to get distracted looking into it *yet*. I have a board to finish first.

 

Matthew

The ColecoVision isn't too complicated. The VDP runs at 3x the 3.579... MHz frequency (for NTSC of course). The GROMCLK output isn't used. The interrupt output from the chip goes to the NMI line of the Z80. Video memory is 16K.

 

It's a TMS9928A, which as far as I can tell is virtually the same as the TMS9918A, except it has the color difference outputs instead of composite (but from your perspective, who cares). There's also no external video input mixing available, for what it's worth. The colors may be slightly different between the two chips, but the rest of the ColecoVision hardware (RF output, etc.) changes the colors anyway. you can Google the color schemes to finds some additional information, but I don't think it's too critical. Typically the ColecoVision's color output is relatively saturated compared to the TMS datasheet anyway, from what I've seen.

 

I don't consider myself a CV programming guru. I use C and the related libraries, so I don't get too in-depth with the hardware when programming.

 

I'd love to help out with beta testing when the time comes. I'd be able to load any new FPGA code, if that helps (and I have some debugging tools, also). Also, board layout or parts procuremnt and assembly, if that's something you're not interested in doing yourself (I like inexpensive solutions!). Wow, this sounds like a resume - anyway, I'm looking forward to seeing this product available for sale.

[matthew180]

Excellent info! I'm still not sure how the whole board design, manufacturing, and assembly is going to unfold, but I'll keep your offer in mind! I don't cherish the idea of having to hand assemble these things. A few, yes, but I think the initial demand might be higher than I'm anticipating - maybe. Maybe that's wishful thinking...

 

Matthew

[Tursi]

My public ColecoVision work is on my webpage in the usual place (http://harmlesslion.com/software) - there's just my TI game ports there for now (Super Space Acer and Waterville Rescue).

 

It's not a bad machine, it feels a lot like the TI (and it should, since all the important hardware is the same ). I don't bother doing a lot of assembly, just the odd routine here and there and tweaking up the output of the C compiler when it really sucks (as opposed to just generally sucking.. but I read SDCC 3.0 is better).

[matthew180]

So on the CV, how are you getting your code into the unit. Do you have a development cart or something? Just curious.

[+5-11under]

So on the CV, how are you getting your code into the unit. Do you have a development cart or something? Just curious.

I use the Atarimax USB cart (or SD cart), or EPROMs/EEPROMs on a PCB.

[+OLD CS1]

The prospect of programming games on the ColecoVision is actually pretty exciting. Partly because of the familiar video hardware, but also because Z80 assembly is actually quite fun. Not as fun, I would say, as 6502 or 68000, but I think everyone has their preference of processor.

 

I was poking around looking for information on the cartridge format of the ColecoVision and could not find anything useful. In particular, there is an FAQ which discusses the BIOS, which says it looks for a header and then transfers control to the cartridge. Ok, where?

[matthew180]

Again, not my point. My point would be illustrated by this (hypothetical) series of events:

 

1) You complete your testing and release the device.

2) Someone (me or someone else) discovers that if you flip an unused bit in VDP Register 0 at just the right instant, you get a stable 256-color graphics mode

3) The F18A does not exhibit this glitch

 

It's inevitable, and not really worth a long discussion of, because it's /impossible/ to plan for. But this is the level of detail that I am talking about in my discussions of "differences in implementation".

 

I was pretty conscious of the unused bits and such during the design since I had to consider, and spend time working on, every bit of every register in detail. I know what you're saying though, and it is that kind of weird functionality that will never be possible to fully guarantee, like you said.

 

Unfortunately, on that same note, those bits that are currently marked as "reserved", always shown as "0" in the datasheet, or that don't *appear* to affect anything - most of those bits were used in the 9938/58 to implement the enhanced functionality. So if anyone abuses those bits, and if I implemented some 9938 functionality (80 column mode for example), the I can promise that the F18A will not function 100% like the 9918A. But, neither can the 9938/58.

 

The 9938 data sheet says:

 

"To make the MSX2 a reality, two requirements for the Video Processor were upward compatibility with the existing TMS9918A (the VDP for the MSX) software while increasing the number of functions."

 

"compatibility with existing software" must be restricted to software that follows the guidelines of "documented" 9918A functionality, otherwise they would never have been able to make an enhanced 9918A. I'll have to make the same statement for the F18A if I'm going to add things like 80-column mode, programmable palette, soft switches for the sprites, etc.

 

Anyway, I'll do my best to make sure all 99/4A software runs.

 

Matthew