Jump to content

Photo

Geneve - Stock Market Program $$CRASH$$


41 replies to this topic

#1 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • 419 posts
  • Location:Campbellsburg, KY

Posted Thu Dec 21, 2017 8:05 AM

I just got very lucky.  About a week ago, I did a search for that Geneve/MDOS program on the internet and found an article about a demo I had given years ago for the program.  In that article, I recalled seeing the program name called $$CRASH$$.

 

All my searching through my remaining diskettes over the years, I had been looking for a disk labeled called "Stock program".  Any diskettes with missing labels, I was cataloging them.

 

Two nights ago as I was doing some troubleshooting, I opened up a small case of diskettes, and low and behold, there sat a diskette and a backup diskette both called $$CRASH$$.

 

I put it into the Geneve, and it was the program I had been searching for 13 years right underneath my nose.

 

The code has the Save routine removed.  It is only 2 lines of code missing and I watched Peter Muys comment out those two lines years ago and I know it is minimal effort to add them back.  I just have to disassemble the code, find the save routine, and add a couple of lines of code for setting up the Save PAB in the XOP, and reassemble.  I exchanged messages with Peter, and he has now blessed the program can be distributed, etc. without any restrictions.  So, I will add the code back in and will need to translate some text into English.

 

Last night, I started to use Tom Freeman's MDOS DiSKASSEMBLER.  Unfortunately, the size of the program requires an expanded Geneve and the real Geneve I have is a stock unit with no extra memory.  Looks like I will probably want to do the 32K upgrade for fast ram and may as well do the 64K VRAM as well when I can acquire the chips.

 

For the interim though, I will need to read the diskette into a DSK image and do the disassembly and assembly on the MESS emulation side of things.  Sorry Michael as I haven't moved to MAME yet.  Not sure if the MAME side of things gives me any extra value for the Geneve.  The MESS version I am using is v 0.143u3 August 16, 2011.  It works for me and I rarely if ever use the TI-99/4A emulation.  I've got that setup with the full 2 MB of memory so it should be no issue.

 

Anyways, Peter was ahead of his time with the $$CRASH$$ program with some websites like Yahoo Financials generating all the graphs and stock reports he was doing now on their websites.  As far as the graphic routines, he had graphs that were autoscaling and plotting that was superb!

 

Anyways, I am a happy camper.  If you haven't guessed, you can guess what I will be doing in the next few days once the holidays start.  And, my UDS-10 is set to arrive this afternoon.

 

Beery

 

 

 



#2 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Thu Dec 21, 2017 9:05 AM

Hello Beery,

 

For the interim though, I will need to read the diskette into a DSK image and do the disassembly and assembly on the MESS emulation side of things.  Sorry Michael as I haven't moved to MAME yet.  Not sure if the MAME side of things gives me any extra value for the Geneve.  The MESS version I am using is v 0.143u3 August 16, 2011.  It works for me and I rarely if ever use the TI-99/4A emulation.  I've got that setup with the full 2 MB of memory so it should be no issue.

 

 

concerning MAME, it is just MESS with a bunch of fixes and additions. We just switched names.

 

However, there are good reasons to catch up:

  • Bugs fixed
  • Improved timing, close to real
  • PFM support

The only issue that you may run into - but you should really test it to be sure - is that later MAME releases require more CPU power. You should have a Core2 or Core-i processor.

 

0.143 is really old; keep in mind that if you or other people stick with the old releases, and you have some trouble with it, it means that I have to find my way back into the old code for each of those releases, knowing that these and those glitches have long been fixed, but not in that release.

 

Let me assure you that you can always install a current MAME beside your existing installation. If you are using Windows: MAME does not touch the registry, and you can remove it completely by deleting the folder. I got the impression that people think they have to abandon their working setup, but this is not true. The only issue is that the hard disk format changed once from v4 to v5, but I don't know whether it was before or after your release. And if you save a copy of the mess.ini (mame.ini), you're safe in any case.

 

Maybe if it just means doing me a favor... ?

 

And I can't be serious, I'm putting an extra free support on top! Yes!



#3 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Thu Dec 21, 2017 9:27 AM

However, there are good reasons to catch up:

  • Bugs fixed
  • Improved timing, close to real
  • PFM support

The only issue that you may run into - but you should really test it to be sure - is that later MAME releases require more CPU power. You should have a Core2 or Core-i processor.

 

0.143 is really old; keep in mind that if you or other people stick with the old releases, and you have some trouble with it, it means that I have to find my way back into the old code for each of those releases, knowing that these and those glitches have long been fixed, but not in that release.

 

Let me assure you that you can always install a current MAME beside your existing installation. If you are using Windows: MAME does not touch the registry, and you can remove it completely by deleting the folder. I got the impression that people think they have to abandon their working setup, but this is not true. The only issue is that the hard disk format changed once from v4 to v5, but I don't know whether it was before or after your release. And if you save a copy of the mess.ini (mame.ini), you're safe in any case.

 

Maybe if it just means doing me a favor... ?

 

And I can't be serious, I'm putting an extra free support on top! Yes!

 

Hey Michael,

 

I just checked and my HD images are Version 4. 

 

A couple of questions regarding MAME so I can perhaps make the transition.

 

1. Does MAME have a user interface similar to what I had with MESSUI.exe where I can pick/select DSK and HD images rather than typing in at the command prompt?

2. If so, does the interface allow me to change DSK images without exiting the emulation?

2. Does MAME have a Debug version similar to MESSUID.exe?

3. And finally, I assume there is a CHDMAN program to convert a V4 file to a V5 file?

 

As far as my PC, I have a Win10 system with 16 GB,Quad core, running I think 3.2 GHz on either one or two SSD's in that system.  I do a lot of 4K video editing requiring quite a bit of power, so computer speed is not an issue.

 

Beery



#4 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Thu Dec 21, 2017 9:58 AM

The user interface of MESSUI was abandoned long ago; some unofficial builds still have it. However, you can use the on-screen menu to swap disk images (switch to partial mode with ScrlLock, then press TAB; select file manager). When I finish my Hexbus work, I may have a closer look at the new Lua-based User interface, so we can eventually get to a more comfortable UI.

 

Do you want to have a debug build, or rather to use the built-in debugger? The debug build is interesting for developers of MAME only. I suppose you think of the debugger; start it with "-debug" on the command line.

 

You can convert the hard disk image with TIImageTool. I designed that Java tool to be a good companion when using MAME. TIMT (for short) includes all capabilities of imgtool and chdman.



#5 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Thu Dec 21, 2017 10:28 AM

Well, it looks like the version of the debugger I have is mismatched (older) than the version of MESS and is not compatible anymore.

 

As far as a debugger, it would be the one I can watch the registers and observe the memory going on inside the individual computer being emulated.  My case, the Geneve.

 

Beery



#6 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Thu Dec 21, 2017 11:34 AM

The debugger is an integral part of MAME. That is, how can there be a mismatch of versions?

 

Or are we talking about a different tool? If you install MAME and then launch it with -debug, it starts its own debugger.


Edited by mizapf, Thu Dec 21, 2017 11:37 AM.


#7 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Thu Dec 21, 2017 12:07 PM

The debugger is an integral part of MAME. That is, how can there be a mismatch of versions?

 

Or are we talking about a different tool? If you install MAME and then launch it with -debug, it starts its own debugger.

Was referring to a mismatch with MESS.  As I recalled, I did a build with MESS to create the debug version of the user interface (messguid.exe).  I just did a mess.exe -debug and discovered the debugger pulls up there as well.  Not sure I had ever tried the command line route in the past.

 

Beery



#8 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Thu Dec 21, 2017 2:06 PM

Take care: there are two kinds of debugging.

 

If you run the debug build of MAME (itself), you can debug MAME with the Gnu debugger (gdb), for instance. This is different from the debugger inside MAME, which is intended for debugging the emulated system. The debugger is part of the standard build already.



#9 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Fri Dec 22, 2017 6:35 AM

Michael,

 

I am attaching a DSK image for the CRASH program.  Under MESS, most of the time I pull it up, the screen is not displaying properly though it has pulled up fine at least once when I was in a window.  On my real Geneve, it displays fine.  The program to load is BEURS.  The TERM1A, etc. files are a set of data files that can be viewed.

 

I am in the process of trying to setup MAME, though it is going slowly as I have not figured out how to attach my harddrive and diskette images.  I had to switch out keyboards as my existing keyboard did not have a Scroll-Lock key.  And then, when I got into the individual setup options, I saw nothing permitting me to setup HFDC, floppies, etc.  I'm now setting up a MAMEUI program that hopefully resolves that.  We'll see.....

 

My thoughts are the screen display issue may be tied to something with the mouse, computer speed, or 192K VRAM.  Just a guess.  Anyways, if you are able to pull it up, then all that more to convince me to switch over as whatever is going on with the 9938 has been resolved.  If not, then it looks like I have found a program that has 9938 issues, the first I have seen with an emulator since the Geneve emulation was rolled out.

 

If you have the time, please look it over to see if it pulls up fine.

​Thanks.

 

Beery

 

 

Attached Files



#10 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Fri Dec 22, 2017 12:27 PM

Michael, I made a note in another thread, but BEURS in the CRASH.DKS file above has a video issue.  Something is not being handled properly, or Peter did something very unusual with direct writes to the 9938.  I am going to do a double check to make sure my DSK image can be converted back to a fresh HFE image and run on the Geneve without issue in the rare chance one of the conversion programs had a small "oops".

 

As far as disassembling CRASH, turns out the two files (BEURS/BEURT) are just a tad too large for Tom Freeman's diskassembler to handle.  

 

Are there any other utilities out there than can handle chained files disassembling Geneve code anyone is aware?

 

Beery



#11 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Fri Dec 22, 2017 1:16 PM

TIImageTool has a disassembler.

 

Also, I noted that the 9995 of the Geneve is falsely set to auto-waitstate. Will have to fix that.

 

I can confirm that BEURS does not run on the emulated Geneve at this time. I wanted to transfer the file by xmodem via the serial bridge of TIImageTool, but the new Java seems to have issues with the RXTX library. Oh my. "I just wanted to try..."



#12 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Fri Dec 22, 2017 5:25 PM

 

I can confirm that BEURS does not run on the emulated Geneve at this time. I wanted to transfer the file by xmodem via the serial bridge of TIImageTool, but the new Java seems to have issues with the RXTX library. Oh my. "I just wanted to try..."

 

Michael,

​I did take the DSK image back to a HFE image back over to the Geneve. I can confirm it is definitely a good program on the real Geneve.

 

When the program first pulls up, there is a Title screen that is displayed in some graphics mode.  When you press enter, it then goes into what I believe is a text mode screen.  Between those two different video mode screens on the real Geneve, there is evidence (very quick) of a flicker of vertical lines similar to what is seen under emulation.  Under emulation, it remains.  Under emulation, there is still control with the arrow keys to move the yellow highlighted box to the far right and hit enter.  This exits the program.

 

The command line interpreter display at this point is still messed up, but if you  blindly type "MODE 80", the screen is restored.

 

Hopefully, this may lead you down a path.

 

Diassembly is taking longer than expected.  I did some tricks as I disassembled both image files as DATA files, assembled them as an object file, then ran through Diskassembler.  That reassembly locked up.

 

TIIMAGETOOL was not acceptable with the split program image files as far as I can tell.  May try it on the object file to see if there is any better luck.

 

Beery



#13 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Fri Dec 22, 2017 5:33 PM


TIIMAGETOOL was not acceptable with the split program image files as far as I can tell.

 

Why? Right-click on the binary file, then "disassemble tms99xx". It tries to figure out where the code starts, automatically sets the offset and address base, and if you want to exclude regions, just read the instructions.



#14 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Fri Dec 22, 2017 6:46 PM

Here is a version where I glued together both files. It is not intended to be loaded and run, but just for disassembling. (Of course, I removed the 6-byte header of BEURT and modified the header of BEURS.)

Attached Files


Edited by mizapf, Fri Dec 22, 2017 6:47 PM.


#15 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Fri Dec 22, 2017 9:52 PM

Here is a version where I glued together both files. It is not intended to be loaded and run, but just for disassembling. (Of course, I removed the 6-byte header of BEURT and modified the header of BEURS.)

 

Thanks Michael.  It was not obvious, and I did read the documentation, that there was a way to disassemble both files together as one program.

 

Beery



#16 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Sat Dec 23, 2017 4:22 AM

I merged both files outside of TIMT, in the Linux console, after saving them as plain dumps. Then I imported the new file back into the image (you can use Drag-and-drop).

Instead, you can also disassemble each of the two files, then copy and paste the code into some text editor.

With the "symbolic" option, the diassembler tries to create source code that uses labels instead of addresses. Ideally, the output can be assembled again. This obviously works better with single files.

Yes, I'd be highly interested to find the glitch in the 9938 emulation. It's nice to have a reproducible error, since you have a good chance to track it. The 9938 emulation does not show the same high quality as the TMS9928.

#17 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Sun Dec 24, 2017 1:56 PM

Michael,

 

While your bin file could be disassembled by TIIMAGETOOL, I had to go back and use Diskassembler instead using some other tricks.  The issue wasn't so much an issue with the disassembly as it was not knowing where the label would be in the file.  If I could suggest an enhancement to the save text file to DV80 file, it would be an option to split the file up by number of lines so TI-Writer or My-Word could handle smaller pieces.  As it was, the disassembled file was converted to a DV80 file over 900 sectors in length.

 

Tom Freman's disk assembler has a field in the DV80 file after the opcodes that shows what the actual words were so a B @ES could be interrupted to a B @ES      >0460,>3804.  So, I could then go into the section of code where >3804 was and continue.   At the end of each 80 character line, there was also a reference word for where in memory the current code was.  For me, it was just something easier to follow.  It has its negatives as it does make the disassembled source files larger, but in the case of TEXT strings, another field will actually show those words as text strings or a "." as a non-printable character.

 

My workaround with Diskassembler turned out to be to disassemble each file as DATA statements.  Then, reassemble into a D/F 80 object file.  At that point, Diskassembler could then load the D/F 80 file for disassembly.

 

Diskassembler did have some issues though with it interpreting some code that AORG'd (when it should not have been), and a couple of other spots where I believe it thought the word was the LWP opcode.  I had to change those to Data statements.  When it was all said and done, the file has been disassembled and can be reassembled again producing a working program.

 

I've been wading through the code.  There is some direct video writes, and there is code using the video XOP's to write to video registers.  The program does drop into Graphics Mode #7 (256x212) to display the intro screen before jumping to the next screen.  I'm trying to wade through all that code to find the trigger copying pieces of code for a separate program that can reproduce it.  Unfortunately, there are a lot of graphics going on with that first screen.

 

Anyways, some progress is being made.  Just time consuming.  As far as doing an English version of the program, the  disassembly still has issues as insertion of any new code is giving it some hiccups and locking up the program.  Once I find the 9938 troublesome code, I will probably go back to TIIMAGETOOL and do a disassembly again and have to work from that source.

 

Again, thank you for your efforts.



#18 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Sun Dec 24, 2017 3:44 PM

Hi Beery,

 

thanks for the suggestions, I'll take a note.

 

If you can identify locations in the code that may cause issues, please note the addresses. In MAME's debugger you can set breakpoints for these locations, so we can more easily find out where things go wrong.


Edited by mizapf, Sun Dec 24, 2017 3:44 PM.


#19 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Sun Dec 24, 2017 6:51 PM

Hi Beery,

 

thanks for the suggestions, I'll take a note.

 

If you can identify locations in the code that may cause issues, please note the addresses. In MAME's debugger you can set breakpoints for these locations, so we can more easily find out where things go wrong.

 

Michael,

 

I started another thread that details about the most basic of programs that duplicates a problem.  While I can not confirm there could be other 9938 access issues, I suspect if this one issue is solved, it will likely fix any other issue if it is a key timing issue.

 

Beery



#20 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Tue Dec 26, 2017 6:36 AM

So it should look like this?
 
I added the following lines in v9938.cpp:

 
void v99x8_device::update_command()
{
   // V9938 ops only work in SCREENs 5-8; mode must not be changed while
   // a command is executing
   if (m_vdp_engine && m_mode<5)
   {
     LOG("Command aborted due to mode change\n");
     m_vdp_engine = nullptr;
   }
   ...
}
 
 
This will be available on end of January (or you have to pull it from Github and build by yourself, which is much easier than it sounds).

Attached Files



#21 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Tue Dec 26, 2017 3:25 PM

The solution above may be sufficient to solve this specific problem, but there are still a lot of open questions.

 

So I wanted to check whether the command is also aborted when switching between graphics modes (e.g. from G7 to G6). Status register 2 of the v9938 has a bit named "CE" which is 1 while a command is executed. Accordingly, we should be able to find out how long a command is running by polling that status register bit. If it is true that the command is aborted with a mode switch, we should immediately find this bit reset.

 

I wrote a small program for the emulation and my real Geneve which switches to G7, then waits for the command to complete, switches back to T2, then outputs the number of iterations when polling status register 2 until the CE bit is reset. The image below contains this program.

 

When we don't switch modes until the command has completed, we get 19000 iterations. However, when we switch from G7 to T2 before the command has completed, we get 17500 iterations. This means that the command is not aborted when switching modes, although it seems to have no effect. It remains to see what really happens; the "solution" from above is wrong, anyway.

 

Maybe you want to do some tests on your own.

Attached Files



#22 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Mon Jan 8, 2018 3:49 PM

OK folks.  For any Geneve emulator users or for anyone wanting to copy the files over, I am uploading a 1.44 MB image of $$CRASH$4 by Peter Muys.  In order for it to display on MESS or MAME, it required the Title Screen to be ignored.

 

If you want to see what was being worked on in 1990, here is the program along with a sample data file of some stocks back in 1989/1990.  I have a !README file on the DSK image as well as all the disassembled source files along with some of my notes.

 

After seeing some issues (undeveloped features) and without the original source code, no further development is going to occur.  Peter has indicated anyone can do anything with the code or program.

 

Enjoy, play, etc.

​Beery

 

Attached Files



#23 InsaneMultitasker ONLINE  

InsaneMultitasker

    River Patroller

  • 2,081 posts

Posted Mon Jan 8, 2018 7:12 PM

OK folks.  For any Geneve emulator users or for anyone wanting to copy the files over, I am uploading a 1.44 MB image of $$CRASH$4 by Peter Muys.  In order for it to display on MESS or MAME, it required the Title Screen to be ignored.

 

Thank you Beery! 

 

On a somewhat related note, I would recommend that you not use 1.44MB images in the future.  With exception of version 6.70RC2 (and even that version needs further testing), the MDOS sector allocation/bitmap routines are buggy for 1.44MB and larger formats due to a cluster calculation bug.  720K and 360k capacities are not affected.



#24 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • Topic Starter
  • 419 posts
  • Location:Campbellsburg, KY

Posted Tue Jan 9, 2018 8:35 AM

 

Thank you Beery! 

 

On a somewhat related note, I would recommend that you not use 1.44MB images in the future.  With exception of version 6.70RC2 (and even that version needs further testing), the MDOS sector allocation/bitmap routines are buggy for 1.44MB and larger formats due to a cluster calculation bug.  720K and 360k capacities are not affected.

Thanks Tim.  Was not aware there was an issue with 1.44 MB floppies and the Geneve.  Good to know.  Is 6.70RC2 out there?  Or being tested?



#25 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,251 posts
  • Location:Germany

Posted Tue Jan 9, 2018 8:51 AM

Also, another note: If you want to work with 80-track images in MAME, you must specify that you want to use an 80-track floppy drive. Or, in other words: You cannot read 80-track images with 40-track drives (surprise :-) ).

 

mame64 geneve -peb:slot8 hfdc -peb:slot8:hfdc:f1 35dd ...

 

Beware - if you work with an 80-track drive in MAME, your 40-track images will become unreadable on 40-track drives once you write to them.

 

The safest bet is still DSDD40.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users