Jump to content
retroclouds

Stevie ("TiVi") Development Thread

Recommended Posts

1 hour ago, retroclouds said:

ok, I solved this stupid, stupid bug that took me too much time 😁

 

The problem was that R15 did not contain >8C02 at the time the TI-Disk Controller DSR was entered.  >8C02 is the VDP port address.

 

Might be a check to add to classic99; verify that R15 contains value >8C02 when the TI Disk Controller is entered 

 

 

That brings back memories.  When I adapted Jeff Brown's interrupt method in TIMXT terminal emulator, I encountered the same gotcha. Within the DSRLNK routine, I added code to save R15 and change its contents to >8C02 prior to calling the ROM routine; afterwards I restored R15. 

 

What I didn't see you mention is that the workspace in question is GPLWS >83E0.  The standard DSRLNK routines have their own workspace however, they use a LWPI >83E0 just before entering routine in ROM.  Depending on the calling workspace and version of DSRLNK, you may also find other values munged, including R14 and/or R13. 

  • Like 2

Share this post


Link to post
Share on other sites

Incidentally, I just found my bug where I was looking at a value to be a 1 or 0, and found that I have the variable a BSS of 1 instead of a BSS 2.

Stupid stuff, and it took me quite awhile.

 

 

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, retroclouds said:

Might be a check to add to classic99; verify that R15 contains value >8C02 when the TI Disk Controller is entered 

Done, thanks for sharing the result!

 

It'll be a while before I can push any changes, though... my local internet is extremely throttled right now.

 

  • Like 1

Share this post


Link to post
Share on other sites
41 minutes ago, InsaneMultitasker said:

What I didn't see you mention is that the workspace in question is GPLWS >83E0.  The standard DSRLNK routines have their own workspace however, they use a LWPI >83E0 just before entering routine in ROM.  Depending on the calling workspace and version of DSRLNK, you may also find other values munged, including R14 and/or R13. 

Classic99 does have a check already for GPLWS on DSR entry. I wasn't sure if there were any bits in R14 (GPL Status) that needed to be set. I know you can confuse the interrupt routine with certain settings, but not sure if the DSRs care on entry...?

 

  • Like 1

Share this post


Link to post
Share on other sites
17 minutes ago, Tursi said:

Classic99 does have a check already for GPLWS on DSR entry. I wasn't sure if there were any bits in R14 (GPL Status) that needed to be set. I know you can confuse the interrupt routine with certain settings, but not sure if the DSRs care on entry...?

 

It's easy to confuse the programmers even if the DSRs don't care. :)   I don't recall a case where R14 was problematic which doesn't mean much these days hehe.    In the Geneve environment I save GPLWS R13 (GROM) and few other bytes when emulating DSR support but I think that is specific to the dark incantations needed to force the two environments to play nicely, versus any specific requirements by the TI ROM DSRs.

 

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, retroclouds said:

ok, I solved this stupid, stupid bug that took me too much time 😁

The problem was that R15 did not contain >8C02 at the time the TI-Disk Controller DSR was entered.  >8C02 is the VDP port address.

Due to the fact that R15 was >0000 at the time the TI Disk Controller DSR was entered, obviously no byte was ever read from VDP memory and the DSR could not check if it owned the VDP file buffer itself and went into a loop between >4744 - and >4754

Might be a check to add to classic99; verify that R15 contains value >8C02 when the TI Disk Controller is entered 

 

5 hours ago, InsaneMultitasker said:

That brings back memories.  When I adapted Jeff Brown's interrupt method in TIMXT terminal emulator, I encountered the same gotcha. Within the DSRLNK routine, I added code to save R15 and change its contents to >8C02 prior to calling the ROM routine; afterwards I restored R15. 

           What I didn't see you mention is that the workspace in question is GPLWS >83E0.  The standard DSRLNK routines have their own workspace however, they use a LWPI >83E0 just before entering routine in ROM.  Depending on the calling workspace and version of DSRLNK, you may also find other values munged, including R14 and/or R13. 

 

3 hours ago, InsaneMultitasker said:

It's easy to confuse the programmers even if the DSRs don't care. :)   I don't recall a case where R14 was problematic which doesn't mean much these days hehe.    In the Geneve environment I save GPLWS R13 (GROM) and few other bytes when emulating DSR support but I think that is specific to the dark incantations needed to force the two environments to play nicely, versus any specific requirements by the TI ROM DSRs.

 

Here  is the layout of the last 3 registers of GPL Workspace expected by console and DSR routines when the GPL Workspace is current:

  • R13 (>83FA) Current GROM Port (>9800)
  • R14 (>83FC)
    • MSB (>83FC) VDP Interrupt Timer (byte at >8379) Tick (usually >01)
    • LSB (83FD) GPL Flags
      • >20 Cassette Operations
      • >10 Cassette Verify
      • >08 16 KiB VRAM
      • >02 Multicolor Mode
      • >01 Sound Table in VRAM
  • R15 (>83FE) VDP Write Address (>8C02)

...lee

  • Like 4

Share this post


Link to post
Share on other sites

Has been a while since I updated this thread.

 

Development is not dead, I've been doing a ton of changes and enhancements in the last year. 

 

I'm currently workin on block stuff (mark block, delete, copy, move, ...).

Would like to get a beta out by Christmas, but it's currently unlikely it will happen as I want to add some more essential things before I release the beta.

I'll see if I can do a video in the next days.

 

js99er-20201212174137.thumb.png.aeff92f66b52b355396906ec30cffafe.png

  • Like 6

Share this post


Link to post
Share on other sites

Have been a little quiet about my current Stevie development activities. Due to personal reasons I was not able to work much on Stevie in the last few weeks of 2020. 

So I didn't manage to get a first beta out. Anyway, I'll first release the beta if I think I managed all milestones I defined for myself. This will take some more time.

 

In the meantime here's a short video where I demonstrate block marking, copy, delete and saving code block to file. 

 

  • Like 8

Share this post


Link to post
Share on other sites

Another update:

 

I've got the block commands working (copy, move, delete, save block). I'm rather pleased with the results. Speed is very good for the most part.

 

Deleting a few hundreds lines of code sure is fast enough. If you have a 100 KB file and start doing copies in the first lines, then it can get rather slow.

I've got a strategy for dealing with that, but it does mean a rather large code change handling SAMS and I don't plan on doing any more changes/enhancements for this version.

Only bugfixes for now as I want to get the first beta out of the door.

 

On a sidenote, I've moved from a 16KB ROM to a 32KB ROM.

 

*--------------------------------------------------------------
* Bank order (non-inverted)
*--------------------------------------------------------------
bank0 equ >6000 ; Jill
bank1 equ >6002 ; James
bank2 equ >6004 ; Jacky
bank3 equ >6006 ; John

 

This is what the 4 banks do:

  • Jill: Startup code (Memory setup, copies spectra2 code to RAM, copies some low-level Stevie routines to RAM (used in multiple banks) 
  • James: Does the heavy lifting, main part of the editor
  • Jacky: File load/save functionality
  • John: Dialog stuff

 

EDIT: All in all I've reached a status where the editor at least doesn't crash that often any more. That means that SAMS memory handling is working properly for the most part.

Edited by retroclouds
  • Like 4

Share this post


Link to post
Share on other sites
6 hours ago, Vorticon said:

Excellent work Philip! Truly impressive.

I know somebody that's gotta up their game. :) 

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites
On 1/13/2021 at 2:55 AM, TheBF said:

I know somebody that's gotta up their game. :) 

Not really, there are plenty of functionalities you have that are not available in Stevie. 🙂


But I am finally approaching the first public beta. Currently doing some polishing and more bug-fixing. Looking forward to the release, because after that I'll probably take a break for a while.

  • Like 1
  • Thanks 2

Share this post


Link to post
Share on other sites

It's amazing to see SAMS memory used as it was supposed to be used. Sorry, but a haven't watched all the demoes: how do you load a file?

  • Like 3

Share this post


Link to post
Share on other sites
4 minutes ago, Asmusr said:

It's amazing to see SAMS memory used as it was supposed to be used. Sorry, but a haven't watched all the demoes: how do you load a file?

Press Ctrl - O (Open file) and a dialog will appear where you can enter the filename.

In the first post I’ve listed the current key mapping. In this version everything is pretty much controlled by key combinations.

 

  • Like 2

Share this post


Link to post
Share on other sites

Thought I’d give an update on what to expect in the first public beta I released yesterday.

 

Stevie v1.0 BETA 1

 

System requirements

 

First some details on the system requirements. This is the setup you will need to run Stevie on the real deal:

 

Required:

  • TI-99/4A Home Computer
  • F18a MK1 VDP (80 columns mode/30 rows with sprite support)
  • SAMS 1MB card (will work with smaller version, but not tested and there’s no RAM boundary testing in place)

Highly recommended:

  • TIPI (as PEB card or standalone with 1MB SAMS expansion)
  • HRD4000B ramdisk.

Alternative:

  • js99er emulator

 

I’m aware that’s a setup that’s limiting the scope for many of you, mainly due to the lacking availability of the F18a VDP.

However, I’m convinced that will change in the future. And at that time it’s good to be ready with the editor.

 

Had very good results with file loading/saving on both the TIPI and the HRD4000B.

Same goes for the standard TI floppy disk controller.

Also tried the IDE and works there as well (but had mixed results due to my Seagate drive being partly broken).
 

In terms of compatibility it’s important to know I’m only doing level 3 file I/O.

Reasoning is that I think it offers the best compatibility among the storage devices out there.
And it’s reasonably fast (at least on the HRD4000B, IDE and TIPI).

 

Also note that Stevie support device paths (e.g. for TIPI) and has an option to skip the VDP when loading files for those DSR’s that support that (e.g. ROS on the HRD4000B, IDE DSR, etc.)

 

 

Testing and bugfixing

 

Development testing was done with the js99’er emulator.

That’s currently the only emulator that emulates the F18a in 80 rows, 30 columns mode combined with sprite support.The cursor in Stevie is a sprite. 

 

I’m planning on supporting classic99 in a future release when I’ll do the enhancements for supporting the V9938 and V9958. It implies that for these VDP’s the cursor handling will no longer can be done with a sprite, and won’t be able to have position based color attributes (need to verify that).

 

Really tried my best to fix as many bugs as possible. I know there are still edge cases that crash the editor. 

Chances you’ll see the editor stall in a loop with garbled VDP are small though.

I have tons of asserts in the code that trigger the “crash screen”.  

Reasoning is that if something goes wrong, it’s better to immediately halt the editor instead of moving on and possible corrupting file during saving later on. With that being said, make sure you have backups of the files you edit with Stevie. Things can and will go wrong.

 

When doing bug-reports please add a screenshot of the crash screen, it will tremendiously help in identifyng the cause of the issue.

 

Vorticon did a lot of testing in the previous internal alpha versions. His feedback was very valuable.

In fact he encouraged me to have block commands (copy, move, delete) in there as well as search and replace.

Both of these I did not have on my task list for the first release.

Managed to cram the block commands in there. Unfortunately search and replace will have to wait for a future release. So a big thanks to Vorticon for doing the testing. It’s very much appreciated.

 

 

Next steps

 

I’m not planning on introducing any new features in the initial release.

The editor should be rock solid and any new features that get introduced increase the risk of something not working as expected. That’s especially the case when programming in assembly language.

There will be a Stevie v1 beta 2. If there will be more betas depend on the user feedback.

 

 

Roadmap for future releases

 

I have a ton of stuff I want to include in the editor.

 

Besides doing more changes in SAMS memory handling (speedup for large files) first things to come will be catalog and file picker, multi-file editing and code templates. Then next up is integration with perhaps a c99 compiler and an assembler. Also want to do tight integration with Basic and make the editor configurable.

 

I also want to abstract some of the code in such way that it can run on other TMS9900x equiped computers.

And last but not least add support for the V9958 as I want Stevie to run on Fabrice’s Tiny-99 system.

Edited by retroclouds
  • Like 5

Share this post


Link to post
Share on other sites

Currently working on preparing Stevie v1.0 BETA 2. This means ironing out some bugs still present in BETA 1.

 

As part of the testing I'm working with some larger files. So far I worked with medium sized files of ~ 3000 lines.

For the remaining tests I'm using DV80 files with a minimum of 8000 lines. I have locked the editor to loading files with a size of max. 10200 lines.

 

That's not an issue for a 1 Megabyte SAMS card, it boils down to 860KB of editor buffer space required if all lines really contains 80 characters.

For most of the "real" assembly language source code files I loaded so far, it's a lot less though. More in the area of 350-500 KB.

 

The limiting factor at this time is the space required for the index. I have 5 SAMS pages reserved for the index, allowing space for up to 10240 lines.

Reason for having a maximum of 5 SAMS pages is that, when doing index reorganisation, I map these 5 pages into the 32KB  continuous memory area >b000->ffff.

Index reorganisation is what happens when lines get inserted or deleted.

 

If there's interest  I can consider rewriting the index handling so that it can manage a variable amount of index pages. But for now I think that 10200 lines is plenty.

Thinking about it more, probably could bump to 6 SAMS index pages at >a000->ffff for a maximum of 12288 lines without doing too much rework.

Would have to find some space for the stuff I currently have in >a000->afff.

 

For the future I'm considering having a "stable" version of Stevie v1.0 where I probably do more bugfixing if necessary and a "development" version for the folks that want to experience the newest features.

  • Like 5

Share this post


Link to post
Share on other sites

Released Stevie v1.0 BETA 2. Some stability improvements, polishing and bugfixes.

 

  • Polished about dialog (show all key mappings)
  • Polished color schemes 
  • Bugfix: Properly initialize all SAMS index banks  (fixes potential crash issue for files >2048 lines)
  • Bugfix: Show code block filename instead of editor buffer filename when IO error during block save
  • Bugfix: Show updated counters when saving file
  • Bugfix: Added memory full error during file load
  • Bugfix: Don't crash editor when reaching bottom of file after delete operation
  • Bugfix: Properly refresh frame buffer when at end of editor buffer
  • Bugfix: Refresh screen early when starting file load operation

 

Get the cartridge binary in post #1

 

Edited by retroclouds
  • Like 5

Share this post


Link to post
Share on other sites

Today's a special day. I finally got around releasing Stevie 1.0

Grab the ROM in the official release thread. 

 

 

 

Source code is available on Github.  Still have to add a markup page, but there you go.

 

Basically there are 2 repositories involved that need to match in order to make a successful build:

The way my build process works, is that I push my commits to a local Bitbucket installation. In there I have a plugin that then pushes all changes to GitHub.
Both github repositories where private before and I've opened them to the public this evening, now that I know things are kinda stable.

(well you can still look at the many previous releases for a good laugh or two).

 

That being said, you won't be able to build Stevie from source code out of the box. I have some custom build utilities currently not on github.

They do things like moving all files from subdirectories to a build directory, do string replacements, etc.

The scripts are just some hacks and not pretty at all, that's why I don't release them to the public at this time.

Most of it can now be done with xas99 I suppose, but still have to look into that.

 

Anyway, the source code is there for history purposes and if you really want to build it, it's not that hard and you'll manage.

 

I'll be taking a break for a while, it has been quite a ride. Especially the debugging phase was really tough, a lot of hard work. 

It's time to move on and try out new things. Some of it TI-99-4a related and other things less so. Looking forward to both!

 

Anyway. Have fun! 

 

 

EDIT: I very much believe in open source software and I encourage everyone to release source code whenever possible. 😃

  • Like 5

Share this post


Link to post
Share on other sites

Here's a quick status update.

 

I'm currently working on the v1.1 release.

 

I now have a 'TAB' functionality in place. Tab positions are defined the same as in the Editor/Assembler (see manual page 25) and you use 'FCTN-7' to move to the next tab.

At this time there's no possibility to configure tab positions yourself. That will come at a later time when I start working on the configuration management.

 

I'm thinking that for the configuration GUI I'd like to implement it in extended basic and compile it with @senior_falcon's compiler and then turn it into a cartridge image that I bundle with Stevie.

That way I can concentrate on doing the editor stuff in assembly language and make good progress nonetheless.
 

Next up are some experimental features I want to add to v1.1 (e.g. better highlighting current line and cursor, directory & file picker, etc.)

 

Also found a bug in the stable Stevie v1.0 release. If you toggle between insert/overwrite mode too fast or too often, the editor crashes or locks up.

Issues can be reported/tracked here: https://github.com/MirrorPusher/Stevie/issues

Share this post


Link to post
Share on other sites

Took a break on working on Stevie. My development machine was kinda in a non-working state, but it's there again now.

 

Anyway. Here's a short video of some of the stuff I'm working on for v1.1

 

EDIT:

Not shown in the video is the tab functionality. There's room for up to 20 tab position and fctn-7 moves the cursor to the next tab position.

It's currently not yet possible to define your own tab positions. I'll probably implement that when the config stuff is in place.

Forgot to mention, the ruler is toggled on/off by pressing ^U

 

  • Like 9

Share this post


Link to post
Share on other sites

I'm currently working on a Stevie revision for classic99. This means I have to let go of the F18a 30x80 mode with sprites. 
Instead it's 24x80 with a character based cursor and ruler.
 

But you get a lot of stuff in return; (1) the CLIP. device, (2) speed, (3) the integrated classic99 debugger.

The Classic99 debugger immediately pointed to a bug in my F18a detection code, so I'm happy about that.

  • Like 6

Share this post


Link to post
Share on other sites

Here's a short demo of things I'm working on in Stevie right now.

 

The idea is that I can jump from the editor into TI Basic.

Do some stuff there and then return to the editor from TI Basic with the current file still present in the editor.

It's not there yet. But should be doable.

 

 

  • Like 5

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