retroclouds

Thank you, it is much appreciated! Yes, I will be adding Pilot 99 to the DevRes thread.

Just found the below book online. If you read through the foreword you learn that Microsoft Multiplan was compiled on a PDP-11 running unix and then the p-code was offloaded to the (home) computer where it gets executed by the P-interpreter. http://cs.brown.edu/courses/cs190/2008/documents/restricted/Writing Solid Code.pdf

Bumping this old thread. Would someone be able to "save" the above documents from the yahoo group and post it here before they get lost in space and time?

Here's a quick update on the development of TiVi. First of all, development has not stalled. On the contrary I've been making very good progress in the last few months. But I also decided to do some major refactoring along the way. Most important, there are some critical changes coming in the way memory is handled. First of all I have removed all code that is dealing with the plain 32K version of the editor. I need to focus as making major program changes when developing in assembly language can be a real pain. I stated at the beginning that F18A and SAMS are the primary target. What I've done is that by aligning all editor structures (editor buffer, index, command buffer, frame buffer, etc) to 4K boundaries I can just flip the corresponding SAM page. That was not possible with the mixed SAMS/32K layout I had been working on in the beginning. By doing this switch to 4K boundaries a lot of stuff gets easier. I also started working on the command buffer, which is basically like a command shell in the editor. The idea is that I can run editor commands, but also some other external stuff from inside the editor. As some of you know, the TiVi editor is build using spectra2 (which you can consider like a small kernel for doing background things, reading keyboard, etc.). I've been making a lot of changes there as well too. In the most critical places I now have some "assert functionality" implemented which lets me crash TiVi in a controlled way. It's a lot better than having to deal with runaway loops while copying memory for example. In the critical places I have something like this: .... ci tmp0,>7fff ; Insane address ? jgt fh.file.read.crash ; Yes, crash! jmp fh.file.read.sams.load1 ; All checks passed, continue. ;-------------------------- ; Check failed, crash CPU! ;-------------------------- fh.file.read.crash: mov r11,@>ffce ; \ Save caller address bl @cpu.crash ; / Crash and halt system ;------------------------------------------------------ ; Show "loading indicator 1" ;------------------------------------------------------ fh.file.read.sams.load1: mov @fh.callback1,tmp0 bl *tmp0 ; Run callback function ;------------------------------------------------------ ; Copy PAB header to VDP ;------------------------------------------------------ fh.file.read.sams.pabheader: bl @cpym2v data fh.vpab,fh.file.pab.header,9 ; Copy PAB header to VDP Here's the crash screen. By saving the PC, caller address, register content and referencing the source list file really helps a lot when troubleshooting.

This is so cool! Thank you for setting up the Github repo and wiki! It is much appreciated 😀

It appears both windows are cleared with a single call. Would you consider an option to specify the window you want to clear?

Wonder how they would look like when printed on vinyl sticker. 😀

I'm using my HDR ramdisk a lot while developing my TiVi editor. It's a real time saver. It's especially helpful when dealing with large files (which is kinda my primary purpose why I started working on TiVi). Today I read the updated documenation the InsaneMultitasker provided as draft. In there I learned that with ROS it's possible to use data buffers that reside in CPU RAM insead of VDP RAM. That is something I really want to try, because even with a RAMDISK reading a large file (think >100 kilobytes) takes some time. Now my challenge is; How can I easily detect from assembly language if I'm dealing with a "high-speed" disk device compared to a "slow" disk device ("floppy"). With a high-speed device I mean: CF7+, Nanopeb TIPI HDR ... I see differents possible paths here: CRC checksum on DSR space (but won't work with RAMBOS? Self modifiying code, configuration stored here too?) Check on some specific device feature? Actually I think that the CRC checksum logic would work quite well (I already did a test program on that about a year ago), but I'm not sure about HDR. Thinking about it would be cool if there is some unified way to detect device capabilities accross devices. For example a standard where there's a device "capabilities" file that is automatically created when the device is formatted. That file could then be processed from TI-Basic, assembly language or any other language supporting file I/O. Any ideas?

Thanks for informing us.

Perhaps we should make this is an own thread. Beery, is the GenASM source code available? Documentation?

Hi, I was the one who created the SPECTRA2 library. Basically it was developed in parallel with Pitfall! Back at the time the assembler I used was Burrsofts Asm994a, because there wasn't much else really. Asm994a did a great job. That being said, in the meantime I switched to xas99 http://endlos99.github.io/xdt99 which is the preferred assembler to use in 2020 if you ask me (one feature I for example really appreciate are long labels). Also it's open source and there's active development. It has been a long time since SPECTRA2 was initially released (10 years to be exactly). I now have a new SPECTRA2 version (unfortunately without documentation yet) and that's the reason I didn't release it. But it is being used for developing TiVi (a text editor). Anyway, to the issue you are experiencing. It won't be until the weekend, but if you like I can take a look at what is happening if you send me your source code. Also if you want to do testing with a debugger I'd suggest you take a look at the classic99 emulator and the js99er emulator. During development I really never used win994a as emulator, only its assembler. Cheers retroclouds

Yes, I'll be there too! 😎

That's cool. Just checked. It's a 20 minutes drive for me (about 19 kilometres). I'll be there! 😎

Impressive! You're on a roll Arcadeshopper. First sidecar SAMS and now this! Congratulations and thank you for your invest and what you are doing for the TI community. 😎

With the new SAMS devices coming up, I thought now might be a good time to show how to make good use of it. 😎

I would advise that if there is a possibility to send from inside Europe (e.g. hungary) to Europe that is certainly an option. In the last few years I've had quite some effort having to go to german customs to pay european import taxes (or worse not being allowed to take the US electronics with me because they don't conform to the european CE-label (had that with the colecovision phoenix). EDIT: I'm also interested in one, but only when shipping from inside Europe. Don't mind paying extra for ArcadeShopper, just hate the hassle having to go pickup the electronics in person at customs.

The game was originally released for the john guidry boards where the banks need to be in reversed order. That is the reason why the original cartridge version doesn't work out-of-the box for the final grom. The bank order needs to be switched for that. But as you have a working binary now, someone apparently already took care of this (can't remember if I did that or if it was someone else). EDIT: the "flickering" as you mentioned it has to do with how the vine is rendered. Can imagine that the amount of flickering even depends if you are on a TMS9918, TMS9928 or F18A GPU. For further details refer to the source code. Just noticed that on feb 20th, it will be 10 years since I released the game on cartridge. Crazy feels like yesterday 🙄

Finally got around trying this today. That is such a cool game, I am very impressed! 😃 Imagine what could have been if we had such high-quality games back in the 80's on our TI-99/4a.

That is crazy, I love it! Thank you for your hard work on this. Bump n jump was always one if my favorite games in the arcade. Can‘t wait to try it out this evening.

Taking a break on the RLE stuff and started work on SAMS itself. List of open topics and WIPs is getting longer, but that is fine. Today I did another major redesign of the index again. Turns out that the way I described above is becoming too much of a hassle to implement, as it severely limits the number of SAMS pages I could address. So I will be following another more easy approach, which will also give me more flexibility regarding number of SAMS banks. The previous index redesign increased the possibility to index 2048 lines instead of 1024 lines. Fine so far, certainly keeping the number of lines. When using SAMS I will have a "shadow" index on another SAMS page, but same size and same addressing. Instead of the pointer to the line, it contains the SAMS page where the line of code is stored. So it's basically just another 4K page kept in sync with the index itself. Other changes: I have the possibility to load files out of a predefined list, with a single keypress combination (CTRL+0 up to CTRL+9). That's kinda cool especially when using the HRD ramdisk in my PEB. It's superfast. Plan is to enhance the concept to keep up to 10 editor buffers open at once (When using SAMS that should be easy to accomplish). Keeping my fingers crossed. 8K cartridge space is now mostly filled, so will have to start thinking about bank-switching. Probably will have something like: 1st bank: TiVi editor code 2nd bank: TiVi file handling code (loading/saving, file selection, etc.)

Tim, let me know if you need help with getting stuff to GitHub. Do you do your source code editing on the TI-99/4a or Geneve or are you using a PC? (When using a PC with Microsoft Visual Studio Code you can for example push all your code changes to GitHub with no effort. I'm doing that with my TiVi assembler source code. I have a private repo on GitHub, when I'm done changing source code in Visual Studio Code it's pushed to GitHub for offsite backup purpose).

The TI BASIC stuff sounds fascinating. Wonder if original documented source code is still available somewhere. Also if there are any original documents on Monitor and Extended Basic. Keeping my fingers crossed! Thanks for sharing, it is very much appreciated! 😎

Ralph, not sure if this has been asked before or if this is already possible; Would it be possible to set address boundaries? If during assembly the PC crosses the boundary a warning/error is generated. Simple case, assembling for an 8K cartridge (>6000 - >7fff) and program is too big, so PC goes beyond >7fff which ofcourse yields unpredictable results. To make this not too specific for this case, it would be cool if "protected" or "allowed" memory areas could be defined via pragma, hint or parameter.

Yes, that would be great. Thanks!

Would it make sense to make this a configuration option?