Jump to content
IGNORED

New MAME release


mizapf

Recommended Posts

44 minutes ago, mizapf said:

 

I did not have any issues with the 99/2 last time. The issue was that no files longer than 1 sector could be read or written, but I solved that one. Please give me another error description so that I can check.

 

Maybe there is also a problem with double density? For all operation with the HX5102 (99/2 and 99/8), I recommend to use single density only, since the DD formats do not match with the 99/4A (and I cannot even guarantee that my TIImageTool would not break the disk format when you use it with the DD16 disks).

i'll test the 99/2 with the same disk that worked with the 99/8 tomorrow. probably that I was using DSDD disk with it too why it didn't work.

Link to comment
Share on other sites

I seem to remember one more issue with double density, and I did not have a solution for that. In rare cases, the density detection fails, and the controller assumes FM (single density) instead of MFM (double density). In a debug log I found that some values in double density read like an IDAM in single density.

 

Trying to explain briefly: The Index Address Mark (IDAM) is a special bit sequence that cannot be produced by normal data, so it can be used to put marks on the track where the sectors start. There seems to be a chance that some MFM data bit sequence looks like an IDAM when incorrectly read in FM. Imagine you hear a music recording at half speed and come to believe you heard "Paul is dead", and then decide this was the correct speed. So the HX5102 starts with SD, believes to have found an IDAM, and then fails. Normally (what the other controllers do) after the read error, the controller should retry with the other density, and then report I/O error x6 if it fails again, but the HX5102 did not retry. This could be a bug in the HX5102 DSR, but I cannot rule out an emulation issue either.

 

Long speech, short sense (long story short): Stay with double sided single density (DSSD, 180K, 720 sectors) for now; you can use sector dump, track dump, or HFE, and the image tools like TIdir or TIImageTool won't do any harm to it.

Link to comment
Share on other sites

3 hours ago, mizapf said:

I seem to remember one more issue with double density, and I did not have a solution for that. In rare cases, the density detection fails, and the controller assumes FM (single density) instead of MFM (double density). In a debug log I found that some values in double density read like an IDAM in single density.

 

Trying to explain briefly: The Index Address Mark (IDAM) is a special bit sequence that cannot be produced by normal data, so it can be used to put marks on the track where the sectors start. There seems to be a chance that some MFM data bit sequence looks like an IDAM when incorrectly read in FM. Imagine you hear a music recording at half speed and come to believe you heard "Paul is dead", and then decide this was the correct speed. So the HX5102 starts with SD, believes to have found an IDAM, and then fails. Normally (what the other controllers do) after the read error, the controller should retry with the other density, and then report I/O error x6 if it fails again, but the HX5102 did not retry. This could be a bug in the HX5102 DSR, but I cannot rule out an emulation issue either.

 

Long speech, short sense (long story short): Stay with double sided single density (DSSD, 180K, 720 sectors) for now; you can use sector dump, track dump, or HFE, and the image tools like TIdir or TIImageTool won't do any harm to it.

will do. I'm going to post this note on TI99resources.

Link to comment
Share on other sites

No, I do not plan to support the F18A in MAME.

 

Same reason as with the TIPI: I cannot emulate programmable microcontrollers in MAME, at least not those at such high clock rates. The TI-99/8 with HX5102 runs two TMS9995 processors, and this is almost at the edge of what my PC is able to perform. The only way would be to assume the microcontroller as immutable, as a black box, and then one could simulate its behavior, instead of emulating, at least at the current evolution step. And when it changes, this must always be adapted.

 

I mean, if someone wants to help out here with some coding ambitions ...

  • Like 3
Link to comment
Share on other sites

Right, FPGA. As I understood, it can be reprogrammed in-system, so I should not treat it as immutable, should I? The point is that with an immutable chip, I can easily justify a look-alike emulation, instead of a deep emulation; but once we get to programmable things, I'd have to include the whole processing architecture.

 

Circuitry emulation is everywhere, of course, but wasn't the F18A about a 9900 core at 100 MHz? I'm not sure whether there is any similar circuit in MAME at that clock rate. I'd need to do a lot of assumptions what can be left out, like READY handling, which eats up a lot of performance in the existing 99xx core. Right now I am not  positive enough to put efforts in a F18A emulation, to find out at the end that it won't work.

 

As I said, if there is anyone ready to take a stake, yes, I'd be there for support as far as I can. ?

Link to comment
Share on other sites

I had the f18a chip in my machine at one time (till I sold that machine). the TI99_4ev setup emulates is a lot of what the f18a visually did. sharper picture, 80 column display and all the 80 column software worked with both. what I never got working was the higher graphic displays games on the EV like TI Scramble that the f18a could do. TI Scramble looked at the EV like it was just a stock TI99_4a. I could be totally wrong but wasn't the f18a supposed to emulate the MSX2 video chip and didn't the EV was about the same thing? 

Link to comment
Share on other sites

No, the F18A was not supposed to be 9938-compatible. There were requests for it now and then. If it were only for a clearer picture, then an emulation of the F18A would not deliver anything new in the emulated TI. From what I saw, the F18A allows for a lot of additional, programmed features.

Link to comment
Share on other sites

1 hour ago, mizapf said:

No, the F18A was not supposed to be 9938-compatible. There were requests for it now and then. If it were only for a clearer picture, then an emulation of the F18A would not deliver anything new in the emulated TI. From what I saw, the F18A allows for a lot of additional, programmed features.

The lack of memory on F18 is a real problem.

Other graphic modes the 9938 and 9958 were in line with the 9918 in design thus allowing 4 times the size number of pixels and in every Graphic mode including interlaced modes.

I was easy to tie GPL to the 9938 and 9958 as the code was very similar to 9918 and just larger numbers for programming ease.

F18 is a great additional device, but pales in comparison to 9938 or 9958 in results or screen size or memory.

 

  • Like 1
Link to comment
Share on other sites

3 hours ago, hloberg said:

hum, we need to get @matthew180 in on this. my f18a, from my point of view, was nothing more than a 9938 upgrade that also provided VGA. there may been other stuff though that I was unaware of.

 

 

yes you are unaware.. it's not even a 9938 upgrade. its  9918/a replacement..with vga out.. and addons..but it's only designed to be as compatible with 9918/a as possible.

  • Like 5
Link to comment
Share on other sites

11 hours ago, mizapf said:

Right, FPGA. As I understood, it can be reprogrammed in-system, so I should not treat it as immutable, should I? The point is that with an immutable chip, I can easily justify a look-alike emulation, instead of a deep emulation; but once we get to programmable things, I'd have to include the whole processing architecture.

 

Circuitry emulation is everywhere, of course, but wasn't the F18A about a 9900 core at 100 MHz? I'm not sure whether there is any similar circuit in MAME at that clock rate. I'd need to do a lot of assumptions what can be left out, like READY handling, which eats up a lot of performance in the existing 99xx core. Right now I am not  positive enough to put efforts in a F18A emulation, to find out at the end that it won't work.

 

As I said, if there is anyone ready to take a stake, yes, I'd be there for support as far as I can. ?

It can be re-programmed in-system, but that's not a normal use case. Many programmable logics can be upgraded, I don't think being able to do so is a requirement of emulation. It's no different than saying "well, board revision 1.0 and board revision 1.2 are different", and claiming you need to emulate the transistor circuit in order to support both. ;) The reprogramming is actually just re-writing the EEPROM that the FPGA loads from.

 

Yes, the F18A has a 9900 /compatible/ core that clocks at 100MHz. But it is not a 9900. It doesn't support any of the hardware control lines, for instance (so there is no READY line). It doesn't support movable workspace - rather it has 16 fixed registers. It has a handful of different opcodes. And the timing is completely different, most instructions complete in a clock or two. Matt is better able to list the specifics, but I've written a bit of code to push it. That said, you can subclass the 9900 emulation and get 90% of the way there - that's exactly what Classic99 did. The extra 10% is just a couple of overrides for opcodes and timing.

 

The additional graphics and sprite modes are what /most/ people are using the F18A for. There are only a couple of apps using the GPU so far. Rasmus has plenty of test applications to verify behaviour.

 

Though for a "next" step, it seems adding support for the SID Blaster would be decent. People want to work with that card, and MAME has all the parts already. ;)

 

  • Like 2
Link to comment
Share on other sites

Ok, so this feels like it is turning into another F18A vs 99938 discussion, and this is not even the right thread to be talking about this.

 

The goals of the F18A MK1 have not changed since 2011, and I have enumerated the goals many times.  The answers are here in the forum and on my website(s), so please take the time to do a little searching.

 

The *primary* goal of the F18A was to allow me to use my 99/4A with a VGA monitor, because I did not want to use a TV, and I always hated the crappy composite image from the 9918A.  All other F18A features are a bonus.  When I finished implementing the original 9918A functionality, there were a lot of unused resources in the FPGA, so I foolishly started adding features to fill up the design.  I was very aware of the 9938's extended registers, and tried to avoid them, or use the same registers in the same way, mostly in case I managed to implement a 9938 in the future.

 

The F18A MK1 and the 9938 are very different, and comparing them should not be done, they were designed with different goals.  The F18A can do things the 9938 can only dream of, or that it could not do until the 9958 (i.e. horizontal pixel scrolling, etc.), and the 9938 has video "modes" that do not exist on the F18A.  But enumerating the differences is a waste of time, as is comparing the two VDPs.

 

I tried to add features to the F18A that were in-line with the capabilities of the computers that originally had the 9918A/9928/9929 VDP.  A few more bits per pixel, some hardware support for scrolling, more sprites on a line, etc.  These capabilities were the kinds of small changes that set arcade computers apart from the home computers of the era, and were the kind of visual upgrade that was most appealing to me.  I feel most people do not share my interest in the enhancements, since most of the F18A's features remain unused, save for a few very nice programs that people have written (I am very grateful any time someone uses the F18A's features, and I'm not discrediting the hard work by those who have done such software).

 

@mizapf From your comments above, it seems you and I disagree about the definition of "reprogrammable" when it comes to something like a microcontroller vs. programmable logic.  Almost no arcade computer in MAME is void of some sort of programmable logic IC, yet they are all emulated without hesitation.  Custom ICs, all emulated.  CPUs like the 68000 and other very fast CPUs (custom or otherwise), all emulated.  I have not looked in a long time, but I have to imagine that MAME is emulating some pretty advanced arcade hardware these days.

 

The bulk of the F18A is a 9918A compatible VDP, with some ideas borrowed from the NES PPU, the 9938, and arcade computers.  Aside from the 9900 core, the F18A itself is not programmable in the way a microcontroller is.  Yes, the circuit loaded into the FPGA can change and make the board something completely different, but at that point it is no longer an F18A, and no one would expect an emulator to emulate the reprogrammable nature of the FPGA itself.  The F18A is just a custom chip, like any other chip on any arcade computer.

 

 

11 hours ago, mizapf said:

but wasn't the F18A about a 9900 core at 100 MHz?

 

No, not really. As I mentioned above, the F18A was about VGA output for the 99/4A, and nice crisp square pixels (the way they should be).  However, having also just done a Joust FPGA implementation, I wanted something like the Williams Blitter in the F18A.  I had about 38% of the FPGA's resources remaining, so I thought it might be neat to try and put a 9900 CPU inside the F18A.  It worked, so I left it in.  Any 9900 CPU emulator could be modified to cover the differences with the F18A's implementation (most of which Tursi mentioned already).  Rasmus has done a full emulation of the F18A with GPU in js99er (which is open source JavaScript, IIRC), and I'm happy to discuss any details and/or differences.

 

The F18A's internal clock is 100MHz, which is needed to pull off the video generation and other multiplexing of resources needed to make things work.  So the 9900 core (GPU) benefits from that, but with modern computers I think getting emulation close to that is possible.  The GPU is also not optimized, with most instructions taking 4 to 10 clock cycles to complete, depending on things like addressing modes and such.  And even when matching the actual speed is not possible, js99er has shown that running as fast as possible is usually good enough.  There is also very little software that uses the GPU, so just having the F18A's enhanced register set and fixed functionality, and ignoring the GPU, would get you almost 100% compatibility with the existing F18A specific software.

 

I do hope, one day, to write an F18A reference core in C (or Ada).  But other things (like finishing the MK2) are taking priority these days.

 

  • Like 5
  • Thanks 1
Link to comment
Share on other sites

@matthew180Thank you for the details. Most of the arcade chips in MAME may be reprogrammable, but they are - as far as I saw - emulated on an as-is state. You would not expect to be able to change them in-system. Hence, the circuits may be high-level emulated, that is, from their external behavior. To fully emulate the features of the F18A, I'd need some 9900 core in one or another way. The existing 9900 core that I wrote in MAME would possibly not work because I emulated it as using a microcode interpreter, and it operates the CLKOUT line and checks the READY input at clock pulse speed, which creates a high load. What I could imagine is to do a completely new 9900 core for the F18A emulation that is stripped off of these details.

 

Any way I turn it, it will require some more work than just for a weekend. Your explanations indeed encourage me to put it on the list.

 

Just to clarify: It's not that I am just too lazy or too stubborn to start working on that. I had some good output in the last weeks while the Corona situation was unclear (this has changed, we now officially do all our lectures online, which causes more work than expected, and I already regret to have let pass so many days). Everyone here who works on bigger project has to prioritize tasks, and unless someone else joins the team, there will be a sequence of things that may not match all expectations.

 

Bottom line: Right now, no plans to emulate the F18A (unless someone...), but it seems doable contrary to earlier concern of mine, so it queues on my list.

  • Like 4
Link to comment
Share on other sites

23 hours ago, mizapf said:

Right, FPGA. As I understood, it can be reprogrammed in-system, so I should not treat it as immutable, should I? The point is that with an immutable chip, I can easily justify a look-alike emulation, instead of a deep emulation; but once we get to programmable things, I'd have to include the whole processing architecture.

 

Circuitry emulation is everywhere, of course, but wasn't the F18A about a 9900 core at 100 MHz? I'm not sure whether there is any similar circuit in MAME at that clock rate. I'd need to do a lot of assumptions what can be left out, like READY handling, which eats up a lot of performance in the existing 99xx core. Right now I am not  positive enough to put efforts in a F18A emulation, to find out at the end that it won't work.

 

As I said, if there is anyone ready to take a stake, yes, I'd be there for support as far as I can. ?

You're not emulating the FPGA chip, only the f18a core.  Things like increasing sprites per scanline shouldn't be an issue.  Js99er is an example of a software emulator that supports f18a.

Link to comment
Share on other sites

15 hours ago, Tursi said:

Though for a "next" step, it seems adding support for the SID Blaster would be decent. People want to work with that card, and MAME has all the parts already. ;)

I've been looking for documentation, but did not really find anything useful. Are there any schematics, memory map, cru map?

Link to comment
Share on other sites

15 hours ago, mizapf said:

I've been looking for documentation, but did not really find anything useful. Are there any schematics, memory map, cru map?

Yeah, you'll have to hit Jim for the truth... all I worked from back in the day was a description of behavior. It's pretty straight forward - it's write-only, and it maps into DSR space when any CRU address below >1000 is accessed.

 

  • Like 1
Link to comment
Share on other sites

On 5/28/2020 at 6:51 AM, mizapf said:

I've been looking for documentation, but did not really find anything useful. Are there any schematics, memory map, cru map?

 

It is kind of abnormal, so what you are seeing as not useful, is probably complete docs... 

 

there are no crubits to set.. It maps itself out of DSR rom space whenever a cru address at or above 1000 is written to, and back into DSR rom space when cru below some number is written... such that a kscan will cause it to map back into memory... the details are in the end user documentation from Marc. 

 

after that, different memory locations in the DSR ROM space are mapped to write addresses on the SID. Also mapped out in Marcs docs... The hardware uses a latch on the data bus to hold the value long enough for the sid to read, while the 4A goes off and does other things... From that and the memory map, seems like you have enough info to re-create this... 

 

Here is the doc from Marc: ( This docs shows malware warnings...  all the data shows up if you say no to loading the untrusted code in the RTF... I'd treat this doc as malware ) 

sidmaster-player_docs.rtf

 

Not the original, but less likely malware: sidmaster-player_docs.pdf

 

Fun fact, it resets the SID everytime it maps it into or out of the memory map... so, if you have a mini-swinSid, everytime you do disk IO on the TI, it goes 'ding' -- I kind of enjoy that.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...