Search the Community
Showing results for tags 'myarc'.
-
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?
- 47 replies
-
- 10
-
Between a rock and a hard place - not enough information to list in AA Market Place and certainly not enough to list on that other E-unnamed selling site. As this isn't the appropriate forum, I'll keep entry short (photos attached). Pricing? Looking to give this Myarc HFDC Hard + Floppy Disk Drive Expansion Card a good home. I purchased it from Tim Tesch the summer of 2019 repaired, but never got around to putting in a PEB and testing it let alone using it. Other than what's available on Ninerpedia, Mainbyte, WHT documentation-wise, I don't know more history about it but I know it's aging away in my '99 part drawers. It didn't come with clamshell or cables, but I'll include a 20-pin + two dual 34-pin cables I purchased new shortly after I got the card. Serious inquiries, I guess PM me as I can monitor AA for a couple days though I don't regularly get around these parts much any more. Doug Myarc HFDC V11.zip
-
Since there doesn't appear to be a manual for 'Advanced BASIC' on whtech (at least not one that's not buried in some inconspicuous disk), I thought I'd start a support thread for advice and tips. So far, I've found that many XB programs can be used exactly as they were designed with just a few adjustments to the program. If you used WDS# for the drive on the TI, it needs to be changed to HDS# for ABASIC on the Geneve. The other important thing is the GRAPHICS subprogram: Set screen to 32-column mode: CALL GRAPHICS(1) Set screen to 80-column mode: CALL GRAPHICS(4) Note that in 80-column mode, CALL COLOR(S,F,B) doesn't work, you must use CALL SCREEN(F,B). (This information was found on mainbyte). ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Here's a text of collected commands. This is pretty much all from the sparse documentation that currently exists, but saves having to dig through generically named RTF files. ABASIC-collected.txt
-
I did some more testing and confirmed that there is indeed a problem with the HFDC DSR. Deleting a file that is fractured will almost always free one or more incorrect sectors. Subsequent writes to these freed sectors will result in corruption, usually by overwriting sectors allocated to other files. According to the letter from Geoff Trott to Beery many years ago: "Item 0545699 94/01/16 19:56 From: GEOFF_TROTT@UOW.EDU.AU@INTERNET# To: BW.MILLER Beery W. Miller -snip- For those that do have HFDCCs and would like a copy of the new EPROM (version 13), if they can get a blank EPROM (27C128 or 27C256) to me at the next meeting or by mail I will be able to program it for them. I will be sending this to Beery Miller for him to distribute for others and the same conditions will hold for people overseas, except I will expe ct something to cover the cost of the postage." Does anyone have a copy of this H13 EPROM from 1994? I have identified the problem routine and came up with a fix that requires four additional bytes (two instructions). Alas, there is no space in the EPROM where I can inject a branch, execute the code, and return. I'm thinking Geoff identified a simpler way to fix this? For the record, the DSR problem shows up when a fractured file is deleted. During the step that frees sectors from the bitmap, the counter that keeps track of the most recent sector (within the cluster) is calculated incorrectly. The value must first be stored in a temporary register then copied for the next iteration. This problem is particularly nasty because every removed cluster compounds the corruption. Edit: To clarify, this DSR problem only affects floppy drives and the DSK1 emulate file. The Geneve is unaffected as its master DSR uses a different routine.