Jump to content
Sign in to follow this  
retroclouds

spectra2 (HW checker)

Recommended Posts

Could someone please try the attached binary on the real deal? It's an 8k cartridge ROM that runs on the unexpanded console.

 

I've been working on enhancing my spectra2 library with some new routines and would like to check if the Hardware is recognized in a reliable way.

 

It should test the below:

 

1. Check if F18A is installed

2. Check if speech synthesizer is available

3. List the VDP refresh rate 50/60Hz

 

 

Thanks.

 

test1c.bin

Edited by retroclouds
  • Like 2

Share this post


Link to post
Share on other sites

Sounds interesting! How will it enhance the unexpanded console?

 

 

Not quite sure where I'm going with this.

 

Basically I'm trying some new ideas, which even some of them aren't even game related.

But hey, if it's good enough for games it should be good enough for doing some "serious" work on the TI-99/4a ;-)

 

Also doing some bug-fixing as I want to use spectra2 for a game in the game contest.

 

I always saw spectra2 as some kind of "mini"-os and want to enhance it a bit further.

Unfortuantely not that much has happened in the last few years. So I'm really sticking to a plan now, that is doing really small steps (as time permits) and see what I can get out of it in 2018.

Edited by retroclouds
  • Like 1

Share this post


Link to post
Share on other sites

On my real iron 99/4a - F18A detected
Speech Synth detected

VDP refresh rate 60Hz

 

All correct for this console.

  • Like 1

Share this post


Link to post
Share on other sites

On my real iron 99/4a - F18A detected

Speech Synth detected

VDP refresh rate 60Hz

 

All correct for this console.

 

 

ok, looks promising :) and thanks for trying.

 

Here is a slightly updated version that should also show the F18A firmware revision.

 

test1c.bin

Edited by retroclouds

Share this post


Link to post
Share on other sites

In JS99er the F18A is not detected after refreshing the browser, but then it's detected after subsequent resets, which means there must be some kind of inconsistency in JS99er. Which method do you use to detect the F18A?

Share this post


Link to post
Share on other sites

You including routines to manage the F18A, as well? Looking forward to the update. Might spur me to actually finish my project.

  • Like 1

Share this post


Link to post
Share on other sites

You including routines to manage the F18A, as well? Looking forward to the update. Might spur me to actually finish my project.

 

Yes, I'm adding a couple of F18A functions as well.

 

Do note that due to some of the changes I'm doing there is no full backwards compatibility with the previous release.

But all in all, these should be rather small changes.

 

One thing to note is that for this release I'm switching from WinAsm99 to Ralphs' xas99 assembler.

Being able to do most of my work in a linux-like environment just gives me a better workflow. I also like that Ralphs' source code is available on GitHub.

Edited by retroclouds

Share this post


Link to post
Share on other sites

In JS99er the F18A is not detected after refreshing the browser, but then it's detected after subsequent resets, which means there must be some kind of inconsistency in JS99er. Which method do you use to detect the F18A?

 

That is interesting. I'm basically running Tursi's solution (GPU code that clears itself) as described in the F18A documentation page 3.

Share this post


Link to post
Share on other sites

 

Yes, I'm adding a couple of F18A functions as well.

 

Do note that due to some of the changes I'm doing there is no full backwards compatibility with the previous release.

But all in all, these should be rather small changes.

 

One thing to note is that for this release I'm switching from WinAsm99 to Ralphs' xas99 assembler.

Being able to do most of my work in a linux-like environment just gives me a better workflow. I also like that Ralphs' source code is available on GitHub.

 

Well, I can change what needs to be changed in my program to make up if I do not stick with the older release. And modify what I need in the new release like I did before :)

 

Now, will it still assemble in WinAsm99? I do not run Linux and I am not keen on fussing with Cygwin (damn thing gives me a migraine, but only half as bad as QuickBooks.)

Share this post


Link to post
Share on other sites

 

Well, I can change what needs to be changed in my program to make up if I do not stick with the older release. And modify what I need in the new release like I did before :)

 

Now, will it still assemble in WinAsm99? I do not run Linux and I am not keen on fussing with Cygwin (damn thing gives me a migraine, but only half as bad as QuickBooks.)

 

At the moment it still does, but dunno if it'll stay that way. I'm splitting up the source code in multiple files so that I can include/skip features as needed.

 

BTW, I'm also on Windows. I'm using the Windows Subsystem for Linux which gives me a linux-like environment in Windows 10. The advantage ist that I till have the possibility to access the files with windows tools, which is important as I'm using classic99 for testing. MS has come a long way and that they are embracing linux is very nice.

 

IMHO I would really encourage you to take a look at Ralph's assembler. It's very nice and as it's Python it should run in Windows natively. Also what I like is that it's a command line tool so it's very easy to integrate into your editor of choice. I'm using vi and have a shortcut key "F4" defined for assembling the current file and creating the binary on the fly. With classic99 I only have to reset the emulator and the cartridge is already loaded. So develop/testing cycles are very short.

Edited by retroclouds

Share this post


Link to post
Share on other sites

 

That is interesting. I'm basically running Tursi's solution (GPU code that clears itself) as described in the F18A documentation page 3.

 

OK, then I think I know what the problem is: my emulator doesn't run the CPU and GPU in true parallel, so sometimes the GPU won't get to run before the CPU tries to read the result. In my own code I'm usually reading the ID in status register 1 to detect the F18A, so that's why I haven't noticed this issue before. It doesn't happen after refreshing the browser but randomly every 8th time or so.

Share this post


Link to post
Share on other sites

To work around that in Classic99 (which has the same issue), I just force a context switch when the GPUGO bit is set - throw away the rest of the main CPU's time and run the GPU now. Seems to work -- could be abused by software that hit GPUGO every couple of instructions, but I can't imagine that having a useful purpose. ;)

Share this post


Link to post
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.

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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...