Search the Community
Showing results for tags 'hrd4000b'.
Found 2 results
I've been doing a couple of tests lately loading and saving a 97KB DV80 file on a real TI-99/4a with PEB, using a couple of different storage devices. To be able to handle such big file I used my Stevie editor with a 1 MB SAMS. Having that much RAM allows me to keep the file completely in memory. The DV80 file I used is the TI Invaders source code as found here: http://aa-ti994a.oratronik.de/TI_Invaders_TI-99_4A_Disk_Version.txt I have tested with following devices: >1000. IDE Card IDE DSR v14 Seagate ST32140A 2GB hard drive First partition IDE1 >1100. Standard TI Disk Controller Freshly formatted BASF floppy disk in drive 1 >1400. TIPI PEB Raspberry PI 3b with 16gb ssd card >1700. HRD4000B ROS 8.42c 4MB RAM disk I clocked total file operation duration using a timer on my mobile phone. For each device I repeated each test 3 times; meaning 3x loading and 3x saving the file. That way I can iron out some of the inaccuracy of my manual timing measurements. To keep compatibility as high as possible, I'm solely using level 3 file I/O. However, for devices that support file buffers in RAM I additionally repeated the test (3x loading, 3x saving), with the buffer in RAM instead of VDP RAM. This is how the test procedure looks like for the load test: Reset console Start Stevie editor Load DV80 from device and time duration until file is shown in editor. Reset console Back to 1 (next device) This is how test procedure looks like for the save test: Reset console Start Stevie editor Load DV80 from HRD4000B partition 1 Save DV80 to device and time duration until file is saved. Reset console Back to 1 (next device) For the sake of science I have spent quite some time on this, repeating the tests over and over 😄 Even though absolute times are not that important (they depend on my file loading handling in the Stevie editor and memory handling specific to Stevie), I do think that comparing times between devices certainly is relevant. With that you get a rough idea what speed the devices offer compared to each other. Durations are in seconds. The "Save slowness" factor indicates how much time the saving of the DV 80 takes, compared to loading. For example, for the TIPI device it means that with the file buffer in VDP RAM, saving the DV80 takes 1,13 times as long.
UPDATE: 2020/07/02 07:05 UTC This thread shall be used for documenting research on Myarc Extended Basic II. Purpose Create a version that can be used with SAMS and a RAM cartridge (superspace) Target modern storage devices like CF7+/Nanopeb, TIPI or HRD4000B. No longer rely on the unobtainable MEMEXP-1 128K/512K memory expansion. Recreate assembly source code Research originated on discussions found here: This post will be updated on a regular basis as more accurate information is collected. BASIC variants (1) Armadillo Basic on the TI-99/8 The new "standard" Basic interpreter on the TI-99/8. Only appeared on some early TI-99/8 prototypes. The plan with Armadillo Basic was that it forms the "basis" for what is later known as Extended Basic II Share as much code as possible between the two basics, Modular setup: One idea was to keep core part of the basic interpreter in ram (statement dispatch table for functions), where it can be modified by the extended basic interpreter startup sequence Interface document exists that outlines the dispatch table Possibility to load & save Extended Basic programs from DV80 files 60K of free space for program code (170K) if 128K memory expansion installed Certain parts rewritten in assembly language for optimized speed (e.g. screen handler) Unknown if source code exists Unknown if ROM dumps exist (2) Extended Basic II on the TI-99/8 Extension of the Armadillo Basic found on early prototype All later TI-99/8 preproduction units had Extended Basic II built-in, instead of Armadillo Basic Unknown if source code exists Confirmed ROM dumps, emulation in MESS/MAME possible. (3) Myarc Extended Basic II on the TI-99/4a is basically (2), the Extended Basic found in the TI-99/8: Written in Assembly language Versions known to exist: v2.10, v.2.11, v.2.12 Memory map changed to match TI-99/4a (+Myarc MEMEXP1) instead of TI-99/8 FREESPACE removed, memory allocation changes, comma instead of dash in list command, ... Removed loading/saving extended basic programs from/to DV80 (at least in >v2.11) Unclear if source code exists (4) Myarc Extended Basic II for the Geneve Written in Assembly language Variant of (3)? It’s the initial version of Extended Basic shipped with the Geneve (5) Myarc Advanced Basic (ABASIC) Written in Assembly language Versions known to exist: 4.04 (last version by Jim Uzzel) 4.05 (~2013 by InsaneMultitasker, fixed assembly language parameter passing bug) Based on (2)? Source code exists, heavily commented Backport to TI-99/4a probably difficult due to the XOP's used (6) Basic on the Tomy Tutor Variant of 99/8 Armadillo Basic Basic tokens compatible with TI Extended Basic GPL involved, but no GROMS (7) TI-Basic on the 99/2 TI internal name “Ground Squirrel BASIC” Developed outside of TI at a contracted university Completely written in assembly language, no GPL involved. Very fast Source code not related to Armadillo Basic (1) on the 99/8 Documents Armadillo Basic on the 99/8 There are actually quite a few documents floating around, created during a 2 years’ period (1982-1984): ?/??/?? - 99/8 Basic / EXT. Basic interface specification ?/??/?? - 99/8 Armadillo Basic specification ?/??/?? - VDP RAM usage in Armadillo Basic 5/26/82 - 99/8 The mapper and us 9/30/82 - Armadillo Basic internal design 3/23/83 - 99/8 Mapper specifications 2/07/84 - 99/8 Bugs found after 7/34/84 release (TI998.BASLCP.BUG) 2/07/84 - Usable XML’s, XOPs (TI998.BASLCP.DOC.ASSM) 2/07/84 - Symbol table entry bits in use for the Armadillo (TI998.BASLCP.DOC.LINKBITS) 2/07/84 - Interpreter variables V0.002 (9/10/82) (TI998.DOC.VARS) 2/07/84 - PAD memory usage (TI998.DOC.PAD) Myarc Extended Basic II on the TI—99/4a Requirements Myarc MEMEXP-1 128K (or 512K) memory expansion card required Has 8K DSR in >4000-5fff (program loader, RAMDISK setup code, spooler?) Myarc Extended Basic II cartridge required It's confirmed that a 8K RAM cartridge (superspace) in >6000-7fff works fine. Disk with Myarc Extended Basic II interpreter Workings When selecting the '128K BYTE O.S.' cartridge option, the file loader in the MEMEXP-1 DSR space is triggered The whole process of loading the Extended Basic II interpreter into the appropriate MEMEXP-1 memory pages seems to be handled from inside DSR space. In the cartridge space the memory management routines required by the interpreter are stored (required for banking the appropriate MEMEXP-1 pages) The code at >6030-7fff seems to be put there are the very end when XBII is loaded into memory. Could be this is part of XBII initialisation itself? When quitting XBII by using "BYE" command the cartridge space >6030-7fff is cleared with >00, only the cartridge header is present. While XBII runs it writes to the cartridge space >6000-61ff (clarify exact memory addresses). This is probably to compensate the fact that the 99/4a only has 256 scratchpad where 99/8 has 1K. Cartridge space: 6000-602F Cartridge header '128K BYTE O.S.' 6030-612F Written to by XBII while running 6130-7fff Appears to be static code, haven't seen any writes here so far Unclarified behaviour The DSR space >4000 is briefly activated every 5-10 seconds while XBII is idling in command mode. This does not happen when a program is running (e.g. 10 GOTO 10). Seems to be a background task: Perhaps the access to the DSR rom space is related to the print buffering code checking to see if anything in the buffer on interrupts?