Which emulator?

[+mizapf]

8 hours ago, Tursi said:

Serial ports are very possible but Classic99 does not support them today. MESS does, though I think only through some sort of simulation and not to the physical port?

 

Yes, more like a simulation. For this serial interface, I implemented an input/output device in MAME that connects to the emulated RS232 and which sends data to a socket (and vice versa). I set up a line protocol that transmits the data byte-wise and also allows for transmitting configuration operations (e.g. set the baud rate).

 

To make use of that serial data stream you need a TCP server that listens on the configured port and accesses the real serial device. This is included as the "serial bridge" inside my TIImageTool. It requires the RXTX Java library. Although control line changes are detected, a safe handshaking proved to be unfeasible because of the buffers in the network path and the buffered UART in the PC.

 

Here is a thorough description; the class names are outdated, however. The principal function is still the same.

https://www.ninerpedia.org/wiki/MESS_Serial_connection

 

(I should add that I still use this serial connection between MAME and my real Geneve from time to time, and it works reliably up to 38400 Baud.)

Edited August 10, 2020 by mizapf

[Tursi]

8 hours ago, apersson850 said:

Thank you. I'll have to look into making larger DSK files to start with.

I usually just take an existing disk image and copy it, then use a disk manager to delete any files on it.  You can also create new images in most of the PC disk management tools.

 

[+OLD CS1]

35 minutes ago, Tursi said:

I usually just take an existing disk image and copy it, then use a disk manager to delete any files on it.  You can also create new images in most of the PC disk management tools.

 

Somewhere around here someone posted several blank DSK images in various sizes.

001_090K_40T_SSSD_E.dsk 001_180K_40T_DSSD_E.dsk 001_360K_40T_DSDD_E.dsk

Edited August 10, 2020 by OLD CS1
Found 'em. Should stick these in a FAQ thread.

[apersson850]

That's convenient.

[eric-bray]

In my opinion when it comes to Emulators/Simulators it all depends on what you want to experience!

For the better graphics I strongly suggest that Classic999 is the program to use.

For sound reproduction that is most like the original TI99/4A, then I suggest using Win994a.

For speech reproduction that is most like the original TI99/4A, again I suggest using Win994a.

For versatility in adding features to the original console I strongly suggest that Classic99 be used with Mame as a strong second choice.

 

Attached are two files that compare the Sound & Speech reproduction of the programs Classic99 and Win994a; you can immediately hear the difference(s) between these two programs. Mame and the other emulators are on par with Classic99 when it comes to those two area of reproduction!!

Lincoln Classic99.mp3 Lincoln Win994a.mp3

Edited August 12, 2020 by eric-bray

[apersson850]

As I wrote in my first question, my primary desire is to be able to use the p-system. Which works in Classic 99.

 

I was thinking a bit about getting files from the TI to the Classic 99, without having to type them in again. If I limit myself to p-system text files, then this seems to be a procedure that would work without the simulator being able to use RS-232.

1. Print the text file to Hyper Terminal, which captures it.
2. Copy the content to Windows clip board.
3. Use the CLIP "device" in the simulator to read it into a DIS/VAR 80 file on a simulated disk drive.
4. Start the p-system with that drive still mounted.
5. Use the Pascal program I wrote many years to allow the p-system to retrieve text from DIS/VAR 80 files and then store it as a p-system text file on another disk.

That should do it, as far as I can see.

But the first thing I need to do is to get rid of the horrendous TI font for lower case letters.

Edited August 12, 2020 by apersson850

[globeron]

11 hours ago, apersson850 said:

As I wrote in my first question, my primary desire is to be able to use the p-system. Which works in Classic 99.

 

I was thinking a bit about getting files from the TI to the Classic 99, without having to type them in again. If I limit myself to p-system text files, then this seems to be a procedure that would work without the simulator being able to use RS-232.

1. Print the text file to Hyper Terminal, which captures it.
2. Copy the content to Windows clip board.
3. Use the CLIP "device" in the simulator to read it into a DIS/VAR 80 file on a simulated disk drive.
4. Start the p-system with that drive still mounted.
5. Use the Pascal program I wrote many years to allow the p-system to retrieve text from DIS/VAR 80 files and then store it as a p-system text file on another disk.

That should do it, as far as I can see.

But the first thing I need to do is to get rid of the horrendous TI font for lower case letters.

 

Hi, if you go to  youtube to my channel "TI99 VIDEOS"  and search on  UCSD P System

I tested I think all the emulators  that support the P-card.  You need the 3x disks like EDitor, ASSmbler and Util?  

 

Furthermore there is a person in the Netherlands (also here on AtariAge) who wrote a Windows program to edit

Pascal files first and he published some programs in TIjdingen.  It it still on my list to test it, but schedule does

not allow as I want to spent more time on it to understand (also I have two P-card here and disks of my father

I need to sort out)

 

PS. these are all the emulators I am running + Michael Zapf's batch files for all the TI systems running in MAME.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[globeron]

 

PS. Antoon Jansen is the expert who wrote these tools, not sure if these are the latest ones:

P-code_tools.doc p-code-tool V2-1-2019-08-24.rar

[apersson850]

Now that would be a neat program, indeed! Had it worked.

But either I'm a bit daft, or it doesn't create text files properly. I tried writing a simple program in Notepad. Then importing that, Get text file, and create a file on the p-system "disk". File is created and so far, so good.

But the p-system's editor can't open it. The p-system text files has a header section (two blocks) on the disk, with various information about the file. Then the text is stored, starting from the next block, in clusters of two. Thus a p-system text file is never smaller than four blocks.

The created file is indeed four blocks too, but the content seems wrong in some way. Or I don't understand how to do the procedure correctly. I did read the manual, but my Dutch is pretty limited, so I may have misunderstood something.

[+Vorticon]

Here's the translated p-code tools document into English.

P-code_tools.doc

[+Vorticon]

I played with the p-code tool, and overall it works great. I was able to replicate the issue of not being able to edit a text file imported from Windows although it does show up in the directory under the p-code system. However, if I edit an existing text file on the diskette, then the edits do show up. So I  suspect that the creation of a new p-code text file is buggy.

One way around this issue is to create a nub of a text file under the pcode system on either a new disk or an existing disk then continue the editing process in Notepad using the p-code tool facility. I tested that and it does work. I do hope the author will get around to correcting that bug at some point though.

One point: there seems to be an issue with accessing the right mouse button menu for the files on disk. Sometimes it works and sometimes not. So yeah, the tool is still a bit rough on the edges, but even as is I have found it to be incredibly useful. I wish I knew about it previously!

Does anyone know the AA handle for Antoon Jansen, the author?

[globeron]

On 8/14/2020 at 1:32 AM, Vorticon said:

I played with the p-code tool, and overall it works great. I was able to replicate the issue of not being able to edit a text file imported from Windows although it does show up in the directory under the p-code system. However, if I edit an existing text file on the diskette, then the edits do show up. So I  suspect that the creation of a new p-code text file is buggy.

One way around this issue is to create a nub of a text file under the pcode system on either a new disk or an existing disk then continue the editing process in Notepad using the p-code tool facility. I tested that and it does work. I do hope the author will get around to correcting that bug at some point though.

One point: there seems to be an issue with accessing the right mouse button menu for the files on disk. Sometimes it works and sometimes not. So yeah, the tool is still a bit rough on the edges, but even as is I have found it to be incredibly useful. I wish I knew about it previously!

Does anyone know the AA handle for Antoon Jansen, the author?

 

I think he is on AA, but let me send him an e-mail.  He published the tool and listings in the Dutch (The Netherlands) TIJdingen.

 

 

 

 

[Rhodanaj]

I am indeed the creator of this tool.

I use it to make Pascal and Assembler programs in P-code.

With this tool I also have a quick way to see the contents of a disk (and the files) and to move the files (by save them first to windows) to an other disk.

I noticed now the error in the text files transferd from windows to the disk and i will fix it in version V2.2

On 8/13/2020 at 8:32 PM, Vorticon said:

One point: there seems to be an issue with accessing the right mouse button menu for the files on disk. Sometimes it works and sometimes not.

I was not able to reproduce the right click error in the file-popup, but i notice that the last popup was still visible when i click om 'empty', i will fix this too.

When there are other problems with this popup or with this program, let me please know.

 

With version V2.1 you can edit a disk that is in use by the emulator, this was not possible in version V1.0. So you can ignore what is told about the need to swap the disks.

With ReLoad and ReSave you can reload or resave the disk that is opened with 'Open Disk', it is a quick way to save and load, but I think, that I do not need to tell, that you have to use it with canniness ... ? When you click on ReLoad in stead of ReSave your changes are gone. Use ReLoad when you made changes on the disk in the emulator, that you want to see in the tool. Use ReSave when you want to save the changes, you made on the disk in the tool, to the disk-file. I did no see the benefit of building in a "are you sure" popup .... 

With 'Open Disk' you can open also some P-code disks that do not have the TI FDR, so you can read P-code disks from some other computers.

The way i used this tool at the moment:

1. Open disk1 with 'Open Disk'

2. Open SYSTEM.WRK.TEXT at the disk in notepad with right-click

3. Make changes in the programfile

4. Save and close notepad

5. Click ReSave

6. Compile the program 

7. When there are some errors I right-click on SYSTEM.WRK.TEXT and make the canges in notepad (at this moment there is no need for ReLoad)

I repeat 5 till 7 until the program is ready

 

 

[+Vorticon]

Since the pcode tool is essentially an Editor/Filer, I can leave that disk out and replace it with the Utilities disk so I can use the Library facility when I make changes to one of the units without having to swap disks and re-initialize the system every time. 

I don't suppose pcode tool supports the large disk images created by apersson? My understanding is that only images up to 720 blocks are supported.

[Rhodanaj]

I use this pcode tool indeed as an Editor/filer.

Of course i can make this tool to support every disk image size you want, but when i was testing a  1440 sector disk, P-code made a big mess of it. That's why I went back to a 720 sector disk (360 sectors in P-code). I assumed this is the maximum that P-code can handle.

Let me test it again with other TI-emulators ( and perhaps without using the Editor/Filer programs.  )

I am using the CADD emulator. 

[apersson850]

On my real TI, I use 360 kb disks (CorComp controller). That's 1440 disk sectors, or 720 p-system blocks. That works fine.

In theory, due to the structure of the p-system's disk directory, it should be able to handle 32767 blocks, provided the underlaying sector I/O routines support that. But it doesn't make any sense, since you can't have more than 77 files on a disk anyway (in IV.0, the version we have).

 

The max size for the proprietary file system in the TI is 400 kbyte disks, due to the size of the disk allocation bit map.

 

With Classic 99, the only emulator I've tried, there's a built-in debugger. With that you can change memory content. Thus you don't even have to write a Pascal program to make six drives available in the emulated p-system. I tried it, and that worked perfectly. Having 2000 block disks didn't, when I really tried to use that size. As more or less could be expected...

 

I realized that I should of course also tell how to get six drives.

 

Look in CPU memory. At these addresses, you'll see this content.

 

2C20-2C60  Table with pointers for different units.
 2C20      0000     #0  (Reserved)
 2C22      2C68     #1  CONSOLE
 2C24      2C68     #2  SYSTERM
 2C26      0000     #3  (Graphic) Reserved for Terak microcomputers.
 2C28      2C70     #4  Diskette name
 2C2A      2C70     #5  Diskette name
 2C2C      2C80     #6  PRINTER
 2C2E      2C80     #7  REMIN
 2C30      2C80     #8  REMOUT
 2C32      2C70     #9  Diskette name
 2C34      0000     #10 (Diskette name)
 2C36      0000     #11 (Diskette name)
 2C38      0000     #12 (Diskette name)
 2C3A      2C70     #13 Assigned to unit loaded from tape.
 2C3C      2C70     #14 OS
 2C3E      2C70     #15
   ...and so on...
 2C5C      2C70     #30
 2C5E      2C88     #31 TAPE
 2C60      2C78     #32 TP

Change it to be like this instead.

2C20-2C60  Table with pointers for different units.
 2C20      0000     #0  (Reserved)
 2C22      2C68     #1  CONSOLE
 2C24      2C68     #2  SYSTERM
 2C26      0000     #3  (Graphic) Reserved for Terak microcomputers.
 2C28      2C70     #4  Diskette name
 2C2A      2C70     #5  Diskette name
 2C2C      2C80     #6  PRINTER
 2C2E      2C80     #7  REMIN
 2C30      2C80     #8  REMOUT
 2C32      2C70     #9  Diskette name
 2C34      2C70     #10 Added disk volume ----------- Here
 2C36      2C70     #11 Added disk volume ----------- Here
 2C38      2C70     #12 Added disk volume ----------- Here
 2C3A      2C70     #13 Assigned to unit loaded from tape.
 2C3C      2C70     #14 OS
 2C3E      2C70     #15
   ...and so on...
 2C5C      2C70     #30
 2C5E      2C88     #31 TAPE
 2C60      2C78     #32 TP

This works on the real TI too. That's how I use four disks with the CorComp controller.

Edited August 16, 2020 by apersson850

[apersson850]

6 hours ago, Rhodanaj said:

I noticed now the error in the text files transferd from windows to the disk and i will fix it in version V2.2

It's probably the creation of the special header p-system text files have that fails. The first two blocks (1 Kbyte) are used to store the things you can see if you use Set Environment in the Editor. When you create a new file, the simplest solution would probably be to just retrieve a copy of this data from a new text file, created by the p-system itself, and just change the minimum required (like the creation date). Maybe there's a size in there too - don't remember.

Edited August 16, 2020 by apersson850

[apersson850]

My intention is to use the emulated p-system for some more serious work, but I just can't stand the horrible standard font. I'll copy the SYSTEM.CHARAC file I have on my real TI first. In the p-system, you can make the system font look like whatever you find prettiest.

 

I have two projects in my mind.

1. Finish the memory loader I started on with my real TI.
2. Make a Native code generator.

The memory loader is supposed to be able to take one code file (assembly) in the p-system, a file which contains routines that should go to different places in memory (including DSR spaces requiring a specific CRU bit to be set for access), and load the whole thing automatically. That would make my three different cards with RAM-based DSR routines load automatically. The code file should be possible to create with the normal Editor and Assembler. Loading should require no manual intervention, so that it could run by itself as a part of (or called from) SYSTEM.STARTUP.

 

The code generator should utilize the ability the p-system already has, with p-codes NAT and NAT-INFO, to run inline assembly. You should just need to mark a critical procedure for conversion, then run the converter and your new code file would be larger but faster.

 

This will give me something to do in hotel rooms...

 

Edited August 16, 2020 by apersson850

[Rhodanaj]

1 hour ago, apersson850 said:

It's probably the creation of the special header p-system text files have that fails. The first two blocks (1 Kbyte) are used to store the things you can see if you use Set Environment in the Editor. When you create a new file, the simplest solution would probably be to just retrieve a copy of this data from a new text file, created by the p-system itself, and just change the minimum required (like the creation date). Maybe there's a size in there too - don't remember.

I made indeed a copy of the first two blocks and only changed the date  

There is no size in these blocks, the last block must be filled up with zeros.

 

Can you test something for me Apersson850?

Can  you import a tekstfile that you could not read in P-code and then with 'CHANGE NAME' append the filename with '.TEXT' (press ReSave) and try to read this file now?

I noticed when i was testing that i can not get a textfile with the Filer G(et command when the filename did not end with '.TEXT' 

(you must not type the '.TEXT' in the Filer G(et command ) 

 

Edited August 16, 2020 by Rhodanaj
append with 'not type '.TEXT' '

[apersson850]

I did try that already when I had the problem the first time, but appending .TEXT didn't help. And the internal file type (that's a numeric value you show in your catalog too) was saying text file. Think it's a 3.

But maybe I appended that from inside the p-system. I'll try that again to be sure. Not right now, though, as I'm at work, Sunday or not.

 

I was not trying to G(et it either, but to open it with the Editor. It gave me an error message. I never use the work file concept.

Edited August 16, 2020 by apersson850

[Rhodanaj]

I does not matter if the .TEXT is appended in the tool or intern.

 

Edited August 16, 2020 by Rhodanaj

[apersson850]

No, and maybe I did something wrong the first time.

Now I tried to import a text file, written in Notepad++, to the p-system using the p-code tool. After importing, I changed the name (added .TEXT at the end) and clicked on ReSave. Then back to the p-system and now it works. Perhaps I did something in the wrong sequence the first time? Perhaps I didn't understand the need to ReSave the first time.

 

Back to regular programming...

Edited August 16, 2020 by apersson850

[Rhodanaj]

Relieved

With the testing i also forgot sometimes to click on ReSave.

When you still have a file, that you can not import as text, let me know and if possible send me this file. 

Perhaps i have to make the import buffer longer, when you have an error with a big file.

 

I will make a version 2.2 where the extention .TEXT will be added right away, when you  import a text-file.

In this new version the text in the block 'Save as' will be on the right place too.

 

The import text command accepts only the ascii characters 32 to 126, the tab (ascii 9) and the return (ascii 13), all other characters are lost.

Let me know if you would like to include those lost charaters in a way like [127] for character 127. (for a programfile this would not help of course.)

Also the length of a line is 77 characters all other characters are lost too. The text-file must be end with a return (ascii 13 and ascii 10) when there is none at the end of the file, the import command will add a ascii 10. 

I noticed at some point during the testing that i got a character 11 at the end of the file, but i could not reproduce it. Version 2.2 will check for a character 11 at the end and remove it.

 

Edited August 16, 2020 by Rhodanaj
big file

[+Vorticon]

There seems to be a major bug with pcode tool.

1. Edit a TEXT file with the pcode tool using Notepad
2. Save your changes and exit Notepad
3. Now try to edit another TEXT file on the same disk. It appears to be completely blank and the size of that file now shows as 4 blocks, as if the tool had just created a new file. The original contents of the file are completely lost unfortunately. Attempting to edit that file from the pcode environment shows it to be filled with "k's.

I am attaching the disk I am using. Try editing the MOVEGEN.TEXT file first, then try to edit the PHOENIX.TEXT file and see what happens. 

Thankfully I had backed up my disk prior to using pcode tool!

Phoenix.dsk

[Rhodanaj]

i will take a look at it !