Jump to content
IGNORED

DX10 Home Computer Software Development System


jbdigriz

Recommended Posts

 

12 hours ago, kl99 said:

After many attempts Piero had success in reading out the operating system disks that I send to him. It is in KryoFlux DiskSystem Format and can not directly be used yet on the machine. So far the disk format (DSDD, 1.153.152 bytes, 288 bytes per sector) is not supported by the Gotek system and Piero has some write issue on his FD1000 that blocks him from creating an actual duplicate disk. But he is on both, getting the Gotek Authors to support this Disk Format (next to the already supported FD800 SSSD 256.256 bytes Format).

Is he using the stock Gotek firmware or the HxC? IIRC KryoFlux streams record the actual raw magnetic reversals on the media, correct? Are there any tools to convert that to sectors, data, and files?

Quote

I am on writing a Windows based tool to analyze the Disk Images. See fd800-tifilelist.txt to see which files on FD800 images it already identified.

 

But you can use a Gotek Device already to boot your DS990/1 with FD800 disk images.

From 15th August (home vacation) I will also work on my DS990/1 system to get it finally running.

Hmm, maybe your one step ahead of me there. Good luck, and let us know how it goes

Edited by jbdigriz
Link to comment
Share on other sites

On 7/27/2020 at 11:38 PM, TheBF said:

I was totally surprised by the Macro file. They were not programming Assembly language. The combination of macros created a simple hi-level language.

Some of it is similar to how a Forth Assembler works.

"Structured Assembly" probably made for more rapid development.

Quote

 

I don't fully grok the stack stuff where they are doing a BLWP ??  Looks like they created a way to push/pop variable numbers of registers.

Very fun to see this. 

Thanks

 

 

 Probably a way to easily and consistently optimize use of scarce scratchpad RAM, I'm thinking.

Edited by jbdigriz
  • Like 1
Link to comment
Share on other sites

On 7/27/2020 at 11:17 PM, InsaneMultitasker said:

 

I almost didn't check out this topic seeing "DX10" -  what a neat set of material you are preserving!  I particularly like seeing comments for things like timing loops, which often get us into trouble when the TI is clocked faster or the card is used with a Geneve.  Very cool.

 

image.thumb.png.b9b25ccfbd5023f2fe61519c5b78cb9f.png

Exactly. "all ur comments are us" ?

Edited by jbdigriz
Link to comment
Share on other sites

On 7/28/2020 at 4:03 AM, jbdigriz said:

Ideally, if we could get all these sources under version control of some kind, it would be a lot easier to generate diffs and patches, reconstruct, and keep track of all the variants. Lotta work OCR'ing, proofing, and typing, but git or something would make collaboration on that easier, too. All you other guys that have been working on reconstructing these sources, what do you think? Lee, Jim, Rich, etc. etc. etc.?  And, Lee, do I need to scan in these 4A console ROM listings, or do you already have the TI-commented sources?

Let's really aim for having it all in a git account in dedicated repositories.

First step done.

https://github.com/kl9900/TMS9900Family

  • Like 2
Link to comment
Share on other sites

Good idea. I suppose it is also available for all kinds of sources and own commented disassemblies from the TI/Geneve systems, i.e. ROMs, DSRs, programs, so we don't have multiple people doing the same analysis individually.

 

We'd have to agree on a structure, like "Consoles", "Peripherals", "Programs" on the top layer, for example.

Link to comment
Share on other sites

7 minutes ago, mizapf said:

Good idea. I suppose it is also available for all kinds of sources and own commented disassemblies from the TI/Geneve systems, i.e. ROMs, DSRs, programs, so we don't have multiple people doing the same analysis individually.

 

We'd have to agree on a structure, like "Consoles", "Peripherals", "Programs" on the top layer, for example.

yes, feel free to go forward (commit) some proposal structure.

Link to comment
Share on other sites

41 minutes ago, kl99 said:

Let's really aim for having it all in a git account in dedicated repositories.

First step done.

https://github.com/kl9900/TMS9900Family

Can GitHub support uploading TIFILES format files, specifically DIS/VAR 80 files.  They would not be readable at the web interface, but could they be downloaded.

 

With DM2K and the TIPI, it is now possible to transfer files from a SCSI or MFM drive over to the TIPI (or back) that makes uploading a bit easier for a Geneve system.  If the files have to be in txt format, not sure if TIDIR can convert them over in a mass conversion format.

 

Not exactly sure how version control would be handled, perhaps just updated TIFILES images of the the individual DIS/VAR 80 files?????

 

I'm asking because at least with MDOS and the Geneve, there is only one program that can put all the source code / object file pieces together, GenProg with GenASM and GenLINK unlike a lot of items on the 4A that can be assembled/compiled now with the xdt tools, etc.

 

Beery

 

Link to comment
Share on other sites

I'd rather see the Github repo as a collaborative playground, not as a file storage. Hence, you'd have to use git for uploading and downloading, which would take care of the version control by itself. The files would also have to be plain ASCII, otherwise it won't make sense, I suppose.

Link to comment
Share on other sites

50 minutes ago, BeeryMiller said:

Can GitHub support uploading TIFILES format files, specifically DIS/VAR 80 files.  They would not be readable at the web interface, but could they be downloaded.

 

With DM2K and the TIPI, it is now possible to transfer files from a SCSI or MFM drive over to the TIPI (or back) that makes uploading a bit easier for a Geneve system.  If the files have to be in txt format, not sure if TIDIR can convert them over in a mass conversion format.

 

Not exactly sure how version control would be handled, perhaps just updated TIFILES images of the the individual DIS/VAR 80 files?????

 

I'm asking because at least with MDOS and the Geneve, there is only one program that can put all the source code / object file pieces together, GenProg with GenASM and GenLINK unlike a lot of items on the 4A that can be assembled/compiled now with the xdt tools, etc.

 

Beery

 

while I see what you aim for, one advantage of version control is to have it in readable format.

so if we commit a TI-File, it will be a binary file on the server and therefore not very readable.

 

I uploaded one assembler source code file for the 99/8 as an example in two formats

https://github.com/kl9900/TMS9900Family/blob/master/Consoles/TI-99/99-8/Rom/DISVAR80/ASSMSUP
https://github.com/kl9900/TMS9900Family/blob/master/Consoles/TI-99/99-8/Rom/TXT/assmsup.txt

 

if you want to commit or check out directly from/to a TI machine (TIPI or some other Device), we should aim for some bridge software to generates the right file format out of the text files.

 

Link to comment
Share on other sites

45 minutes ago, kl99 said:

while I see what you aim for, one advantage of version control is to have it in readable format.

so if we commit a TI-File, it will be a binary file on the server and therefore not very readable.

 

I uploaded one assembler source code file for the 99/8 as an example in two formats

https://github.com/kl9900/TMS9900Family/blob/master/Consoles/TI-99/99-8/Rom/DISVAR80/ASSMSUP
https://github.com/kl9900/TMS9900Family/blob/master/Consoles/TI-99/99-8/Rom/TXT/assmsup.txt

 

if you want to commit or check out directly from/to a TI machine (TIPI or some other Device), we should aim for some bridge software to generates the right file format out of the text files.

 

Don't get me wrong, I completely agree the code should be in readable format.  I just do not know how we would get from DIS/VAR 80 format "easily" to a readable format on GitHub, and then be able to go back the other way to accomplish version control if we are dealing with source code being assembled on a TI-99/4A/Geneve setup versus another compiler on another type of processor.

 

There would really need to be some kind of App for that.  It is a simpler situation when the tool doing the assembly process is a Windows/Linux/Mac (?) application.  More difficult if all development is on the TI-99/4A or Geneve 9640 and there are a significant number of source code files.

 

I don't know if the DX10 uses "source" files that are more like Windows TXT files, or if they are another format.  I bought the subject up since the thread went with the TMS9900Family Github link above and I would like to see something like that for the Geneve with its extensive set of source files.

 

Beery

 

 

 

Link to comment
Share on other sites

It could make sense to also differentiate between original sources and reconstructed sources (by disassembly).

 

I know this is a experimental entry; but I'd suggest one level less:

 

/consoles/

/consoles/ti99_2/

/consoles/ti99_4/

/consoles/ti99_4a/

/consoles/ti99_8/

/consoles/geneve/

 

with above idea:

 

/consoles/ti99_4a/disassembled/

/consoles/ti99_4a/original/

Link to comment
Share on other sites

1 hour ago, retroclouds said:

Not to derail this thread, but I've loaded the 99/8 ROM assmsup.txt source code directly from github into my Stevie editor on the TI-99/4a.

 

 

 

Nice, I presume you used the URI route with the TIPI?

 

Now, figure out the easy way to go the other direction and save it.  Going to throw a note on the TIPI development area for the subject matter.

 

Beery

Link to comment
Share on other sites

Do we have the same plans with the Github repository?

 

I thought it was about keeping source code files for the purpose of archival and analysis, not for actively working with them to create new software. Of course, both can be possible at the same time, but it would be even more important to consider a proper directory structure.

 

The download into Stevie looks good; you can download files from Github via HTTP, of course. But I think you need a proper Git client to upload stuff.

Link to comment
Share on other sites

On 7/27/2020 at 11:17 PM, InsaneMultitasker said:

 

 I particularly like seeing comments for things like timing loops, which often get us into trouble when the TI is clocked faster or the card is used with a Geneve.  Very cool.

 

image.thumb.png.b9b25ccfbd5023f2fe61519c5b78cb9f.png

Am I the only person who uses the 9901 timer as a time reference?

It works great on a real TI-99. 

Would it help to make delays the same on a 99 and Geneve?

Link to comment
Share on other sites

12 hours ago, BeeryMiller said:

Don't get me wrong, I completely agree the code should be in readable format.  I just do not know how we would get from DIS/VAR 80 format "easily" to a readable format on GitHub, and then be able to go back the other way to accomplish version control if we are dealing with source code being assembled on a TI-99/4A/Geneve setup versus another compiler on another type of processor.

 

There would really need to be some kind of App for that.  It is a simpler situation when the tool doing the assembly process is a Windows/Linux/Mac (?) application.  More difficult if all development is on the TI-99/4A or Geneve 9640 and there are a significant number of source code files.

 

I don't know if the DX10 uses "source" files that are more like Windows TXT files, or if they are another format.  I bought the subject up since the thread went with the TMS9900Family Github link above and I would like to see something like that for the Geneve with its extensive set of source files.

 

Beery

 

 

 

I have been noodling on making an app to let the TI-99 do that on Classic99.

It would start the app, give it a DSK?.FILENAME string and then paste PC text to classic99 and it would write to DV80 file.

The reverse would be to write the DV80 file to CLIP and paste it into your PC editor.

Would that do the job?

Link to comment
Share on other sites

44 minutes ago, TheBF said:

Am I the only person who uses the 9901 timer as a time reference?

It works great on a real TI-99. 

Would it help to make delays the same on a 99 and Geneve?

 

You may remember in this thread, TurboForth Assembler, that I used it some, but I was scared off a bit with the discussion of it being a bad idea turning pins on the 9901, hardwired for input, into output pins by running the timer at its maximum setting. I never got back to the project to try sorting out any of that.

 

...lee

  • Like 1
Link to comment
Share on other sites

29 minutes ago, Lee Stewart said:

 

You may remember in this thread, TurboForth Assembler, that I used it some, but I was scared off a bit with the discussion of it being a bad idea turning pins on the 9901, hardwired for input, into output pins by running the timer at its maximum setting. I never got back to the project to try sorting out any of that.

 

...lee

 

Since I forgot about that admonishment I have left Forth running overnight numerous times and the machine is still working.

It could be because I only poll it during a delay. However I am now reading it in my cursor blinking loop so that's pretty frequent but Forth is not really polling continuously since it runs the interpreter every 56 or so micro-seconds and the cursor loop has other stuff in it as well. So either I am lucky or it's not too dangerous. ?

 

All that to say try it you may like it. ?

 

Link to comment
Share on other sites

8 hours ago, BeeryMiller said:

Nice, I presume you used the URI route with the TIPI?

 

Now, figure out the easy way to go the other direction and save it.  Going to throw a note on the TIPI development area for the subject matter.

 

Beery

 

Uploading to GitHub or other GIT repository servers is indeed a completely different cup of tea.

implementing a GIT client on the TI-99/4a is out of the question. 

Guess you would need to use the TIPI as a proxy for doing the heavy lifting (which it already does now, doing the HTTP transfers, etc).

 

If I was to implement something like that (which I’m not, too much other stuff) I’d probably save my files to a directory on the TIPI and have a proxy service that monitors the directory for file changes and mirrors that to GitHub.

With that in place, it would not be difficult to control the service from the TI-99/4a with a simple API for doing commits, etc.

 

When doing it the hard way and trying to implement something like a client on the TI-99/4a for communicating with Github (that’s something different as a plain GIT server), you could try to implement the required github REST calls and parse accordingly.

But then you still have login, https, tokens and a zillion other things you probably need to consider.

 

Link to comment
Share on other sites

8 hours ago, mizapf said:

...

The download into Stevie looks good; you can download files from Github via HTTP, of course. But I think you need a proper Git client to upload stuff.

 

Thanks, it’s nothing more than a trick really. And it shows what TIPI is capable off.

For the TI-99/4a it’s nothing more than a file it’s loading. Still, was quite pleased that my level 3 I/O routines handle it nicely ?

Yes, everything beyond that would require a GIT client.

  • Like 1
Link to comment
Share on other sites

7 hours ago, TheBF said:

I have been noodling on making an app to let the TI-99 do that on Classic99.

It would start the app, give it a DSK?.FILENAME string and then paste PC text to classic99 and it would write to DV80 file.

The reverse would be to write the DV80 file to CLIP and paste it into your PC editor.

Would that do the job?

My particular use would be on the Geneve, either in GPL or MDOS mode. I would really hope that one could select/click the files to transfer, and then it would go and do its thing without any manual intervention.  Take MDOS source for example as there are probably 100+ source files.  Yes, that is an extreme case, but would not want manual intervention if that is what you are thinking.

 

Beery

Link to comment
Share on other sites

As I said, we could use a Github repository both for active development and for documentation/analysis purpose.

 

To give an example for the latter one, and why I deem it important: We have lots of software without source code, remember the Hexbus DSR, or other programs. I am currently digging deep into TASM to find out why it has a (reproducible) issue for the second pass for certain files, because I want to find out whether this is an issue of TASM or GeneveOS. We have some commented source code, too, which should be kept available so that no one invests time in already done work.

 

I recently posted my Hexbus DSR disassembly, which is not complete, and by using a repository, other people could pick up the work and continue with it.

 

Again, this is no mutual exclusion with development work. The only difference is that the documentation/analysis use case does not require any interface to the TI hardware.

Link to comment
Share on other sites

1 hour ago, mizapf said:

To give an example for the latter one, and why I deem it important: We have lots of software without source code, remember the Hexbus DSR, or other programs. I am currently digging deep into TASM to find out why it has a (reproducible) issue for the second pass for certain files, because I want to find out whether this is an issue of TASM or GeneveOS. We have some commented source code, too, which should be kept available so that no one invests time in already done work.

 

Again, this is no mutual exclusion with development work. The only difference is that the documentation/analysis use case does not require any interface to the TI hardware.

I understand your view, and agree.

 

As far as TASM and the Geneve OS, what are you seeing with this reproducible issue?  If this is pointed out somewhere else, just provide a link, etc.

 

Beery

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...