Classic99 Updates

[+mizapf]

Perhaps we should have a general MESS thread for this type of question, but how would you go about emulating the F18A in MESS?

 

At this time, low priority, sorry. I have a huge number of open issues still waiting to be done before.

[Asmusr]

 

At this time, low priority, sorry. I have a huge number of open issues still waiting to be done before.

 

Sorry, I wasn't asking when you would do it, but for the overall principles for adding a device like that to MESS.

[TheMole]

 

Sorry, I wasn't asking when you would do it, but for the overall principles for adding a device like that to MESS.

 

MESS is actually a very nice modular system to develop for. It takes a bit of a reading up to understand how things work together and how the code is organized, but once you get it you'll notice it's actually a very nice design.

 

The components are all independently developed and can be used stand-alone. A machine definition is basically a recipe that defines how the chips that make up a device are connected to each other. Each of these chips is a self-contained piece of code. So to develop F18A support for MESS (which can then be used by every supported MESS system, by the way, so you could re-use it for the colecovision or MSX emulation as well) you would probably start by duplicating or extending the existing 9918a code to include the extra register and memory the F18A has. Besides that you would need to look for the register write functions to extend the internal state machine to include what is needed for the new functions. Then, since MESS renders per scanline, you need to find the scanline rendering function and add support for the extra modes and features such as scrolling register in the scanline rendering function directly.

 

The file you want to start in is http://mamedev.org/source/src/emu/video/tms9928a.c.html

The scanline rendering function is actually where the bulk of the code is, and starts at line 287:

void tms9928a_device::device_timer(emu_timer &timer, device_timer_id id, int param, void *ptr)

For the basic VDP extensions, I don't see much difficulties. For the GPU however... that's a lot less clear cut and really what has kept me from taking a stab at it. I'm scared of what it would take to accurately emulate the 9900 at 100Mhz from within the VDP code and have no idea how you would structure that within the MESS framework. Especially how you would re-use the existing tms9900 core and hook it up to VDP memory... no idea...

 

Of the other emulators, I know ti99sim is closer to classic99 in how it does its VDP emulation in that it always renders the full screen in one go instead of per scanline. For v9t9 I wouldn't know...

[Asmusr]

If someone (m***** ) would set up the skeleton code I think it would be an interesting project to contribute to. I would be able to recover my rusty knowledge of C++.

 

Besides the GPU, the F18A also has two 32 bit counters running at 100 MHz (AFAIK) that I guess would be difficult to emulate accurately. If MESS renders per scanline perhaps the scanline interrupt and associated register values would not be that difficult. But for game development I think the more common VDP functions like sprites, patterns and scrolling would be much more valuable to emulate.

[matthew180]

Heh. I'll write a reference, but I don't know what good it would do anyone. It would be in C/Assembly though, not C++. I don't code using an OO methodology or philosophy, and I avoid languages that support OO constructs whenever possible. Abstractions have their place, but hardware emulation is not one of them.

 

Yes, the F18A has two 32-bit counters and two 32-bit random number generators that "tick" (count or generate) every 10ns. No one has ever used them though, so I was actually considering taking them out. It seemed to me that accurate timing and really fast, large value, random number generation would be very sought after. The F18A also has scan line interrupts which make generation of the actual display a lot harder (I think) since you can't just draw the whole frame as fast as possible and swap a buffer at VSYNC.

 

You let me know what you want in terms of a skeleton and I'll see about making it happen.

[+OLD CS1]

IIRC, the random number generator was a popular item. It they are already there, so why not leave 'em and let someone "find" them?

[Asmusr]

IIRC, the random number generator was a popular item. It they are already there, so why not leave 'em and let someone "find" them?

 

And Kevan might need the counters to build an atomic clock!

[Asmusr]

Heh. I'll write a reference, but I don't know what good it would do anyone. It would be in C/Assembly though, not C++. I don't code using an OO methodology or philosophy, and I avoid languages that support OO constructs whenever possible. Abstractions have their place, but hardware emulation is not one of them.

 

...

 

You let me know what you want in terms of a skeleton and I'll see about making it happen.

 

I thought the MAME/MESS framework would force you to do things certain ways, e.g. use classes for devices. And can you include assembly in MESS, I thought that would be problematic for cross platform compatibility?

[+mizapf]

Matthew said he could imagine to write a reference implementation, but this does not mean it will be included as-is into the MAME/MESS source code. It will, of course, eventually need to be rewritten in C++.

[Asmusr]

Matthew said he could imagine to write a reference implementation, but this does not mean it will be included as-is into the MAME/MESS source code. It will, of course, eventually need to be rewritten in C++.

 

OK, I misunderstood. But a reference implementation would also be very useful, and not only for emulation.

[matthew180]

This might be taking the Classic99 updates thread off topic...

 

A reference would be just that, a reference, and not specifically written to fit into any particular emulator. Otherwise it would not be a "reference", but rather a module for a specific emulator. Also, since C++ is a super-set of C, someone could wrap a class around whatever I would write. However, I'm also not understanding what good it would do anyone to have a reference to begin with?

 

Most emulators try to reproduce the end result and don't concern themselves with accurately emulating the actual way the hardware functions (which is my biggest problem with emulator projects that claim to be preserving or documenting the *hardware*.) So in the case of the F18A I'm not clear on what I would provide? A software representation of the hardware functionality? But that seems unnecessary in most cases.

 

Take the scroll registers for example, they would probably not be emulated the same way they are implemented in hardware, and the end result of their functionality is pretty self-explanatory. Aside from taking the time to actually write the code within a specific emulator framework, there is little to explain.

 

Granted, some features would need a little more information than others, but that is where documentation seems it would be more helpful than a representation of the functionality in code.

 

I plan to talk to Tursi at the Faire about how I might help get F18A functionality into Classic99, but I doubt it will result in me rewriting any part of Classic99.

 

So again, what could I provide that would be useful or helpful, but is not a specific module for a specific emulator?

[matthew180]

IIRC, the random number generator was a popular item. It they are already there, so why not leave 'em and let someone "find" them?

Because they use FPGA resources that could be put to better use. An unused feature is a waste. Not only that, I thought they would be so sought after than I made sure the GPU had its own dedicated counter and RNG separate from the host system's counter and RNG. So not only are they wasting resources, they are wasting 2x the resources. Besides, they will also be incredibly hard to accurately emulate.

[+mizapf]

If we were to implement a F18A in MESS, we would need a precise documentation of its (visible) operation. If we also want to do it cycle-precisely, we need to know the micro program commands that are executed on each cycle, similar to the description of the TMS9900.

 

See 9900-FamilySystemsDesign-04-Hardware Design.pdf on WHTech, pages 4-89 ff.

 

It is not important to know how exactly the microoperation is done, only what is the result after the cycle. In that sense this is already an interpretation of the real machine operations and not a 100% mapping into software.

 

The only thing (apart from the fact that I cannot afford the time right now, as I said) that concerns me is that I heard the internal cycle rate is 100 MHz. This is 25 times faster than the CPU emulations I have been involved in, so I cannot tell whether if in the end we would end up with a simpler emulation.

Edited November 1, 2013 by mizapf

[Omega-TI]

 

And Kevan might need the counters to build an atomic clock!

 

Oh wow, I never thought of that, what a concept for the TI!

Imagine getting one of those little Atomic Time Clocks (they are cheap and in everything) and getting it to pass the current time to the TI in a compatible manner for use in existing programs. I wonder if that could actually be done? I'm drooling at the thought!

 

<COUGH COUGH>

Edited November 1, 2013 by Kevan

[Asmusr]

For me the purpose of emulating the F18A would be to support game development. It doesn't matter much if the GPU is only running at 20%, as long as you can see that your code is working. It's nice that there is a positive difference when you run your code on the hardware.

 

I could continue to hack Classic99 in silence and add the features I need for my own projects, but Classic is coded as a one man project and it's difficult to separate my code from Tursi's. It would be nice to be able to subclass (or whatever the C++ term is) the 9918A class for the F18A and the TMS9900 class for the GPU and slowly add the features you need until some day you have a full emulation.

[matthew180]

If we were to implement a F18A in MESS, we would need a precise documentation of its (visible) operation. If we also want to do it cycle-precisely, we need to know the micro program commands that are executed on each cycle, similar to the description of the TMS9900.

For the 9900-GPU or the video generation? If for everything other than the GPU, that's the problem with a software perspective of hardware, there are no micro instructions and things don't work in a serial nature. The F18A's video parts are just like the original 9918A, i.e. dedicated circuits that build the video display in real time. The closest part to what might be a "program" is the FSM that sequences memory access to get the necessary data to put pixels on the screen. However, the 9918A does this too, and certainly no software emulator has emulated the 9918A FSM.

 

See 9900-FamilySystemsDesign-04-Hardware Design.pdf on WHTech, pages 4-89 ff.

I own the actual book. :-) Read it many many times.

 

It is not important to know how exactly the microoperation is done, only what is the result after the cycle. In that sense this is already an interpretation of the real machine operations and not a 100% mapping into software.

The GPU is a modified implementation of the 9900, so its emulation could be done in the same way I suppose. Start with the 9900 core you already have, add the stack instructions, remove the CRU instructions (mostly). However, like the FSM driving the video part, I have never seen a software emulator focus on emulating the actual hardware, only the *result*. The GPU is not cycle accurate to the original 9900 and just performs operations as fast as it can.

 

The only thing (apart from the fact that I cannot afford the time right now, as I said) that concerns me is that I heard the internal cycle rate is 100 MHz. This is 25 times faster than the CPU emulations I have been involved in, so I cannot tell whether if in the end we would end up with a simpler emulation.

Correct, the F18A uses a 100MHz (100.5MHz actually) clock because I needed a speed that was divisible by the VGA clock of 25.125MHz, and I knew I wanted to eliminate certain limitations of the original VDP like the host-to-VDP speed limit. So every 10ns the internal F18A clock ticks and something happens, i.e. the GPU and video FSMs transition to a new state, internal memory is addressed, etc.

 

Every instruction in the GPU, except for the shift and divide, "execute" in 10ns, i.e. the FSM execution state is only one clock tick. However, the fetch, decode, store, update flags, and memory operations are additional FSM states that make up the what is typically considered a single "instruction". The shift and divide instructions take 16 10ns ticks in the execute state, otherwise they are the same as any other instruction. With all the states and memory accesses, a single instruction typically takes between 160ns and 250ns.

 

The GPU control is not microcoded like the real 9900, it is completely combinatorial logic that settles in one clock cycle (the decode state only takes 10ns). The host-to-VDP interface is FSM driven and triggered by a CSW or CSR request (pin pulled low) to the VDP. The host interface FSM will have completed and gone back to idle before the host system even has a chance to de-assert the CSW or CSR signal, thus removing the speed limit.

 

The video generation FSM builds a single scan line in a buffer since it has to be displayed twice on the VGA screen. The FSM sequences memory access to get pixel data for the current line. The tile data is accessed first, followed by sprite data.

 

Again, keep in mind that all of these FSMs are individual circuits that operate in parallel. Only memory access has to be coordinated between the host interface and the GPU, and the host interface gets priority. The video circuits only need read access to the memory, and since the FPGA's internal block RAM is dual-port no coordination is needed with the GPU or host interface. The video circuits just run full speed and can access RAM every 10ns (which is faster than modern day SDRAM).

 

Each scan line buffer is also a dual-port RAM that is written to by the video FSM at 100MHz, and read out by the video display counters at the 25.125MHz VGA clock rate. But again, I don't think an emulator would do this, so these details a moot.

 

The enhanced functionality based on the new registers is really what would be important, and a lot of that has been documented (although not in a single place, I know.) Aside from the time to code the features and a few details here and there, I'm not clear on what information would be missing to get most of the emulation working? Which again leads back to my question of, what would "reference code" really provide?

Edited November 1, 2013 by matthew180

[Asmusr]

Hi Tursi,

 

Just wondering if you would consider adding a 'run to next vertical refresh' feature to the debugger in the next version of Classic99:

http://atariage.com/forums/topic/165901-classic99-updates/page-28?do=findComment&comment=2836235

It would be extremely useful for my game programming, and for others as well, I think, to be able to see each screen after it has been drawn.

 

Thanks,

Rasmus

[RXB]

With out the extra VDP memory the F18 really does not provide all this effort.

 

Yea it is a very cool new device, but is mostly uncompatible with the coolest software ever made for a TI99/4A like

Funnelweb 80 column

XHI a 9938 Bit Mapped Graphics mode for XB that had 4 Screens of VDP memory of a single TI99/4A

X80 that is 80 column but had 128K of VDP RAM to use for storage

and Y.A.P.P. for 9938 Hi Res Graphics production images.

 

I mean 4 times the screen size the F18 can do and 8 times the memory?

 

I just wish the F18 was upgraded to be more compatible with existing software.

[+arcadeshopper]

With out the extra VDP memory the F18 really does not provide all this effort.

 

Yea it is a very cool new device, but is mostly uncompatible with the coolest software ever made for a TI99/4A like

Funnelweb 80 column

XHI a 9938 Bit Mapped Graphics mode for XB that had 4 Screens of VDP memory of a single TI99/4A

X80 that is 80 column but had 128K of VDP RAM to use for storage

and Y.A.P.P. for 9938 Hi Res Graphics production images.

 

I mean 4 times the screen size the F18 can do and 8 times the memory?

 

I just wish the F18 was upgraded to be more compatible with existing software.

 

I think you should develop a 9938 drop in replacement for the 4/a..so you will be happy

 

Greg

[Asmusr]

With out the extra VDP memory the F18 really does not provide all this effort.

 

Yea it is a very cool new device, but is mostly uncompatible with the coolest software ever made for a TI99/4A like

Funnelweb 80 column

XHI a 9938 Bit Mapped Graphics mode for XB that had 4 Screens of VDP memory of a single TI99/4A

X80 that is 80 column but had 128K of VDP RAM to use for storage

and Y.A.P.P. for 9938 Hi Res Graphics production images.

 

I mean 4 times the screen size the F18 can do and 8 times the memory?

 

I just wish the F18 was upgraded to be more compatible with existing software.

 

 

Looks like you have posted to the wrong thread. This is about Classic99 updates.

[RXB]

Look if every device has a new set of standards and and new completely different set of rules to run by then Classic99 will become mostly bloatware.

 

I am on Tursi side here. Do you expect him to support every new device that ignores all the old standards?

I know the frustration as in RXB I tried to support all the Devices I could but that took more space then the original project to up update XB.

Yea it is a cool new device and yea people love it.

 

I just said I WISHED it was designed to be more backward compatible and not need new standards to just function.

 

Why do I need 3 sets of the same programs just to work with different devices?

[TI-Sissy]

Look if every device has a new set of standards and and new completely different set of rules to run by then Classic99 will become mostly bloatware.

 

I am on Tursi side here. Do you expect him to support every new device that ignores all the old standards?

I know the frustration as in RXB I tried to support all the Devices I could but that took more space then the original project to up update XB.

Yea it is a cool new device and yea people love it.

 

I just said I WISHED it was designed to be more backward compatible and not need new standards to just function.

 

Why do I need 3 sets of the same programs just to work with different devices?

 

i think you just like to complain and argue.

[RXB]

 

i think you just like to complain and argue.

I think you NEVER address the subject and bitch about me. You never address the subject matter or the point of the post.

Instead you launch personal attacks everytime. If you want to debate then you do not personally attack others as it makes you look like the jerk.

 

You notice no one addressed what I said but instead attack me personally. My post until now was not a attack on anyone, just pointing out the facts.

 

And like I asked why do I need 3 different versions of the same program for 3 different devices?

Edited January 26, 2014 by RXB

[+OLD CS1]

You notice no one addressed what I said but instead attack me personally. My post until now was not a attack on anyone, just pointing out the facts.

 

And like I asked why do I need 3 different versions of the same program for 3 different devices?

 

I do not think you should need three different editions of a program for three different devices. But I do think we all use the right tool for the right job, depending upon availability.

 

For instance, the F18A seems to take a bit of heat for not being X or not being Y or not implementing Z functionality, when it is meant to be little more than a modern, drop-in replacement for the TMS-9918A with a few added features to make stock 4As, MSXs, ColecoVisions, or other 9918A-based kit a little more fun and useful.

 

Thanks to the F18A, I can not connect my 99/4A to an SVGA monitor. If I wanted to, I could also play with the built-in 9900-compatible processor. I can also modify my 4A to use a little less power by removing the VDP RAM chips. I can also use some 80 column software, some with and some without modification.

 

It does not make my 4A a Geneve. It does not make my 4A run 9938- or 9958-compatible modes. And so on. And so what? It does exactly what I want it to do. It does exactly what many who have purchased it want it to do. And it might do more later, who knows? But I can guaran-damn-tee that constantly bashing it is not going to encourage additional development on the device, and if there are so many deficiencies in any device created for the TI when why can those who have such a problem with the deficiencies work to make their own device? You know, like building the better mouse trap.

 

I have seen a number of people pushed out of other communities -- several talented Amiga developers who created extremely useful Amiga software and hardware, in particular. The deja-vu around here is worrisome.

 

More to the point, I do not think Tursi should emulate every device which comes down the pike, either. He has done a great job emulating the F18A thus-far and keeping up with many of the requests for Classic99. I do think it is possible for a collaborative effort between him and someone else to provide more F18A functionality, but ultimately it is his program and fully up to him. Does it matter in the end? Maybe not, as we all seem to be resourceful enough to work around not being able to develop for the F18A in emulation. Just that emulators a a great tool since you can do things in emulation you could never do in hardware.

[slinkeey]

i think you just like to complain and argue.

Edited April 19, 2014 by slinkeey