Michael Rittweger

It is fully ok to edit the structure outside the emulation. In fact I did have used your tool already, but used it for chd creation only or so. (Not sure, actual chd might be a result from the imgtool of the MAME package.) I have to admit that I was a bit stuck to TI99Dir while jogging disk images in and out. Unf. that tool exits with a runtime error on some dsk images and I didn't see a way to use chd images yet. I still like the "Norton Commander" like two filelist view, though... But I have totally overlooked the file manipulation possibilites of your tool, I'm afraid. I just had a quick peek at it and it seems to go in the right direction. Thanks for not only the warning but the explanation, too. I just read that warning in the ReadMe of the MDM5 and now I know what it is about. Yep, I will be using the dsk and chd (DSK1 and WDS1) on the TI99/4a side only. I have absolutely no experience with the Geneve and am right now struggling enough to resemble my 80s knowledge of that 4a machine. Later on I definitely will have a look at cards I don't know yet and the Geneve is one of them, of course, too. Michael

Hi, all! I wanted to start using an hdd image (chd for MAME) as kind of backup / archive collection of files I create on the disk (dsk) images. But I'm stuck on the very first step: How do I create a subdir? I can't (and don't want to even if I could) store everything into the root dir. I did see a few references to something like WDS1.SUB.DIR.FILE, but how do I create SUB at WDS1 root? Michael

perfect! thanks!

Hi, all! I remember a little game called (german) "Eimerkette". It was published as BASIC source in one of the home computer magazines. I might be wrong, but it could have been "Happy Computer". It was a bit like a "Go" game. You have to fill up buckets until they swallow their content to the bucktes in the neighborhood. Is there any chance to get that listing / program downloaded off of any disk floating around? Michael

Two days... Two days! Yikes! I implemented a Bresenham algorithm as part of a (starting) library of bitmap subroutines in Assembler. That d**n thing drove me crazy. Either it drew 2 pixels and stopped or drew one pixel to the left where it should head right and all other sorts of effect, including overwriting part of the color table. It was a relatively simple C program (Wikipedia, last example) to be converted, really. And I read it row by row comparing with my Assembler translation, over and over. I didn't see any error. Then suddenly yesterday evening... JLE is not "jump less / equal"!!! And... Exactly this is stated in the E/A manual, too, as an extra hint! *facepalm* Using JLT and JEQ in 2 consecutive lines did the job. Michael

Just an idea how to prevent any problems with "escape" characters or how you'd like to name any of those characters outside of the "normal" character set (32..95 or max. 32..127): A german TV station (WDR - Westdeutscher Rundfunk) transmitted software in the 80s by a scanline of the TV signal outside of the visible area (like "VideoText" is transmitted, too). To prevent problems with "special" characters they used a translation they called "sixeln" (derived from the number "six"). It was quite easy: Let's assume 3 bytes of data: >F3, >41, >07 This is in binary notation: XXXXooXX, oXoooooX, oooooXXX Now cut this line of 3*8 = 24 bit into 4 parts of 6 bit each: XXXXoo, XXoXoo, oooXoo, oooXXX interpret every 6 bit as a new byte of 8 bit (left padded with zero) and add 32 to each value: ooXXXXoo = >3C, +32 = >5C ooXXoXoo = >34, +32 = >54 oooooXoo = >40, +32 = >60 oooooXXX = >07, +32 = >27 Now you have a sequence of 4 Bytes instead of 3, but every byte has a value in the range of 32..92 and will not collide with any restrictions. And decoding is as easy as encoding. Just my $0.02 Michael

Calls itself, yes, but an exit from recursion is not mandatory, although always makes sense. See the dictionary entry: recursion: see recursion The exit from a recursion is only needed, because resources don't allow endless recursion loops. But a fractal (Mandelbrot) graphics for example could be rendered endlessly. You just limit the recursions programmatically, because a) the display can't show smaller details than a pixel and b) the return stack would grow endlessly but not having endless RAM to store it. Thus 100 A=0 110 GOSUB 200 120 END 200 A=A+1 220 GOSUB 200 would be a legitimate recursion, although 100 A=0 110 GOSUB 200 120 END 200 A=A+1 210 IF A>50 THEN 230 220 GOSUB 200 230 RETURN makes much more sense and would not, like the first one, result in a stack overflow / out of memory error. Michael

I'd like to have a peb again, to get started. ;-) I had to dump my peb roughly 2005 when I realized that the hole thing became rusty all over after 15 or so years in the basement. But as far as I can see: Nobody is selling a peb these days. Or is there any source I have overlooked? Michael

Does it have a -joyport and / or does it support -cass1 / -cass2? I'll have to extend the exceptions on those one, too, if not. Michael

Hi, all! Ok, I managed to get the Geneve up and running from the IDE, although I have absolutely no idea what I may type in at that prompt. But anyhow... I added the "memex" to the comboboxes. But there is no ROM file for them, isn't it? Well, the Geneve starts up, so why bother? I made something I really don't like: I coded a few (well, a few more...) exceptions to deal with the Geneve. So, if "geneve" is selected as machine the syntax is a bit different for the whole ioport thingy. I will have to change that ugly hardcoded behaviour some time. I found an unexpected behaviour (wouldn't call it a bug) with the various text fields: If you want to "clear" them, they filled up on next startup again. This was a security branch in the "load settings" routine, that prevented overwriting of values with empty ones, which resulted in default values showing up. I disabled that behaviour. I still have no idea how to implement additional options for e.g. the TIRS232 in an ergonomic way at the IDE tab page. But: I have added an extra "options" textbox on the MAME tab page where you can store those options. That'd be the place for the "-debug" or whatever. A new setup zip is online: 0.3.5.1 Michael

I would, if I would... ;-) I'm only using hfdc as the single controller for floppies and hard drives in my setup. The problem I meant is another one, solely created by me. ;-) The IDE collects the info the for peb slots one after another. After that it scans from 2 to 8 if the inserted card, if any, is a hdc. If yes the slot is kept as device for the following -ioport:peb:slot<x>:<ctrl>:h<y> options. The same is done for the fdc part. That's what I meant: If you put a fdc/hdc combo like the hfdc into slot 6 and another pure fdc like the tifdc into slot 8, then the hdc in slot 6 will be used, because there is no other one, but the fdc in slot8 overrides the one in slot 6. Thus it would result in -ioport:peb:slot6:hfdc:h1 generic -ioport:peb:slot8:tifdc:f1 525dd for example. There is currently no way to use the fdc of the slot 6 hfdc in this configuration. If the hfdc is in slot 8 and the tifdc in slot 6, then both fdc and hdc would be used from slot 8. Pull out the card in slot 6, it's useless in that configuration. And that's what I did. ;-) Michael

Hmmm... There is no "-ioport peb" with the Geneve, too? That rises another problem... Michael

Yep, you're absolutely right with that. As of now the ComboBoxes have a "hard coded" list for their lookups. Later on I would like to have them dynamically filled. So, if you place any ROM or catridge files into the appropriate folders the list would show them up autmatically. But right now I will (just) have to add the entries manually. That's a 5 minute task, indeed. On the other hand... You should be able to manually type in the machine name (or the card name for the peb) into the text field of the ComboBox and that should be saved in the settings then, too. I just tried... Hmmm... There's another (small) problem. The Geneve doesn't know about the -gromport. But de-selecting that one and the cartidge doesn't help: Some line in the code seems to put ExBasic into the cartridge option, even without an actice gromport, and that leads to an error message (at least with MAME) again. I'll check that asap. Are you using the -debug option all the time? I'd suggest to set it in the mame.ini then, until... I will add a textbox to enter additional options for the emulator. (That might help for the next paragraph, too.) What might be a bit more of a task will be the RS232 settings... I'm not quite comfortable with the way I collect the settings for the peb and their slots. I would love to see that more dynamically. Right now it is very static as you can set options for "a" (yes, not "the") f/hdc. The most important drawback as of now: You can only use _one_ controller, kind of. Specifying a fdd in slot 6 and slot 8 will only use slot 8 then. hfdc in slot 6 and tifdc in slot 8 would result in using the fdc from slot 8 and the hdc in slot 6. I'm not sure how I will add options for other cards, like the RS232, right now. I'll have to have a closer look at that tab page after some other, minor changes and extensions. Michael

Seems so... I tried a while to get this d**n thing working, but to no avail. I searched for alternatives and after 3 other attempts I stumbled over "Visual Studio Installer". That one at least produced usable output. I had to change / extend the original project a bit, but then... a setup.exe and a setup.msi came out! You need both of them and so I combined 'em in a "TI xdt99 IDE.zip" file. And the zip for download is found directly from the root in the "Setup" folder. Not using .exe as file extension for the download has some other benefits, too. Although an option "remove previous versions" (internally) is checked it refuses to install over an existing version. You'd have to uninstall via Windows. But hey... Michael

Argh... My first attempt with that "ClickOnce" installer and after getting your response I found: stackoverflow.com: will clickonce be ported to net core 3 as well as winforms That at least sounds as if this could be the problem. I'll have to dig even deeper, but I will have to search for an alternative installer, too, I'm afraid. Michael

Thank you very much for the logfile. I have checked it and wasn't sure at first sight, but after digging a bit deeper... The problem seems to be that the installation routine tries to download (and install) .NET framework 4.8 and fails at this step. I have checked my setup: In the "publish" (see left menu "Veröffentlichen") properties section via "required components..." (see right button "Erforderliche Komponenten...") the .NET framework 4.8 is checked and the option "download from component creator" (see option "Erforderliche ... Komponentenherstellers ...") is checked - that'd be Microsoft. Hmmm... Looks to me as if the download link to their download site is broken. The alternative (2nd option) would be to store a copy for downloading at the (my) GitHub repository, but I'm not sure how and, even more important, if I am allowed to do that. And with the 3rd option I'd have to specify an alternative download link. I'll have a closer look at this problem. And: No, you do not need to have xdt99 installed at this point. The IDE is "standalone" unless you try to start any external applications like the assembler, emulator etc. via the buttons. Up until that point the IDE should start without any error. Thanks for your feedback! Michael

So, as far as I understand: All (currently pre-defined) tools could be used as is, only the cross-assembler itself has to be exchanged. The disk manager to create the disk image and copy / convert the files could still be used from the xdt99 package, like the Basic converter, too. I don't know of a cross assembler for the Geneve, but the xdt99 calls itself "a TMS9900 cross-assembler" and a quick check of the docs didn't reveal any options for creating Geneve compatible output. But if anybody could name a Geneve compatible cross assembler this would be the place to set it up, the XDT tab of the IDE: And please keep in mind: This is a "user" setting that can be changed by the user at any time and will be saved in the user options locally. If somebody replaces one or more of the tools successfully I should consider changing the headline into something more general. Michael

Hmmm... I have to admit: I have absolutely no clue. I don't have _any_ experience with the Geneve at all. But it _may_ be possible, theoretically. The IDE starts an editor with parameters, e.g. the source filename. You may choose another editor instead of NotePad++, of course. This is the Windows side, no Geneve involved. Then the IDE starts an assembler, again with parameters for input, output and other options. Again: Windows side. I have the IDE designed for use with the xdt99, because it has the tools I thought were needed for my needs. But if the functionality can be achieved by another tool (or other tools) that can be set up at the settings tab. The xdt99 cross-assembler produces object (EA3) and image (EA5) output. If the Geneve can use those, then it should be possible. But still yet: Windows side. Next step within the IDE is the creation of the disk (disk image file, to be a bit more accurate). Still: Windows side, but... The disk is created in a format that can be read by MAME and... uhm... the other one... V9T9? Not sure about that right now. The files (object, image etc.) are transferred from their Windows format as DIS/VAR80, DIS/FIX80, PROGRAM etc., according to their designation, to the disk. That's the TI99 side. So after this step there is _one_ file stored in the Windows filesystem that contains one or more files in the TI99 filesystem. So if the Geneve reads the same files from a disk in the same format as the 99, then... You just have to find a way to mount the *.dsk files at the Geneve side (emulator) or write it to a real floppy. And, as much as I want to, I can't help with that. Michael

IDE for developing in TI99 Assembler on the PC (Windows) (using NotePad++ Editor, xdt99 Cross-Assembler and MAME Emulator) https://github.com/miriki/TI-xdt99-IDE/ Hi, all! A few may have noticed: In an xdt99 thread I have published a Batch for DOS that shortens a lot of typing work when developing software. After years of abstinence from the TI99 I actually remembered the "good old days" developing tools and libraries again and tried to recall what I was doing those days. Well, 35 or so years... Firing up the MAME emulator, using TI99_4ev as machine, a cartridge with Editor/Assembler inserted and the needed disk in DSK1 mounted I started typing a few lines while reading through a bunch of books and forum articles. Hmmm... A PC keyboard and the function keys of the TI99, two worlds collide. Yes, the editor _was_ a very good one, at least that days. But nowadays I really, really prefer the comfort of NotePad++ or at least any other GUI based editor. Then I've read about the one or another Cross-Assembler to develop in Windows and using the output to mount within MAME. Almost right from the beginning I got stuck with xdt99, a collection of not only a cross-assembler, but other tools like a "disk creation", too. An integration into "IntelliJ IDEA" sounded good, but.... Hmmm... Maybe I have not digged deep enough, but there is only the editor used for syntax highlighting, isn't it? Putting things together: A batch for DOS (Windows, Microsoft, sorry...) was created that enabled the workflow from editing the Assembler source code assembling the source code into object code creating a disk which contains the object file starting an Emulator with this disk mounted plus a few more tasks... To be honest: I don't like DOS batches with more than, let's say, 25 or so lines. The syntax is ugly and the CLI commands are far from comfortable - not comparable with a high level language. Changing default values is a pain, (re)storing user settings a tremendous effort and doing all with user parameters results in a jungle of % characters shattered across the lines. So I used that batch only as a sketch for a "real" project: An IDE for those tools written in a high level language. I decided on C# (VB.Net would have been the alternative), because it is the preferred language right now in our company. Training... If anybody would like to have a look at it: I just published that project on GitHub. That was kind of training, too. We use Azure DevOps in our company and I have to get familiar with those cloud based team thingy. So hopefully I published correctly - it is my first published project over there. https://github.com/miriki/TI-xdt99-IDE/ This is the main page of the project. There is a README, but empty as of now. You will find a subfolder "TI xdt99 IDE" though... There is a subfolder "snap" which contains a few screenshots of the published project: Settings_Xdt.png shows the settings to include the tools from the xdt99 package. Settings_Mame.png shows parameters for the emulator, including configuration of the peripherals etc. Settings_Ide.png shows the standard working area with buttons to start actions and checkboxes to set options. Output_CommandStack.png shows the list of calls to external tools like the editor, assembler etc. Output_Standard.png shows the standard output of the last command, for example the directory of the disk. Output_Errors.png shows the error output of the last command, if there is any. Emulator_AutoStart.png shows the XB output from DSK1.LOAD if "catalog" and "autostart" is checked. Output_Result.png shows the loaded and started demo program I was just working on. Another subfolder "publish" contains a "setup.exe" that should install the IDE. I'd like to get feedback, if that thing runs without any problems. But what has to be done? Well... Perhaps it is best to show my setup: E:\TI99 mame64.exe >roms ti99_*.zip >hash ti99_cart.xml (thanks again, mizapf!) >cart editass.zip minimem.zip exbasic.zip >disk *.dsk >hard *.chd This should be enough to start MAME using e.g. ti99_4ev as machine. Try it... mame64 ti99_4a If successful, try inserting a cartride: mame64 ti99_4a -gromport single -cart exbasic If successful, try connecting a peb with a hfdc in slot 8, a disk drive connected and a disk inserted: mame64 ti99_4a -gromport single -cart exbasic -ioport peb -ioport:peb:slot8 hfdc -ioport:peb:slot8:hfdc:f1 525dd -flop1 disk/flopdsk1.dsk whew... After the first start of MAME there will be a few more subdirs like cfg, nvram etc. You might like to start MAME with -createconfig and edit the output mame.ini to suit your needs. I added cart and cart2 subdirs to the roms path, disabled the info screen at startup and the like... Then I added a subdir >xdt99 xas99.py xdm99.py xbas99.py >lib vdptools.a99 >projects >gmode gmode1.a99 etc. The "lib" folder contains a "vdptools.a99" file right now. There are only a few routines to avoid "BLWP VSBW" etc. in it. The "projects" folder contains the, as you already might have guessed, projects I am working on - for example a "gmode" subfolder. And in the "gmode" folder there are gmode1.a99, tmode.a99, mulcol.a99 and bitmap.a99. With this setup the settings on the XDT and MAME tabs should be self explanatory, kind of... The right hand side shows extensions for the filenames. For example the source "gmode1" gets expanded to "gmode1.a99" for the editor, is compiled into "gmode1.obj" and will become "GMODE1O" when copied to the TI disk. You may change the settings on the MAME tab and can use the IDE purely as a frontend, if you like. The "run" button will start the emulator without fiddling around with an assembler or anything else. BTW: Settings are loaded at startup of the IDE and saved when the IDE is closed or any external program is called. The IDE tab is the "all singing, all dancing" desktop for your development. The left box lists all subdirs aka projects, the right box lists the source files in that (selected) project. The selection is shown additionally in the two textboxes in the upper right (for later extensions). The "edit" button starts the editor, the "assemble" buttons starts the xdt99 cross assembler. It creates the object, image and rpk files, if checked. If "all" is checked, not only the actual selected source but all within the project will be assembled. The "disk" button creates the disk to be mounted for the emulator. It copies the source, list, object and image files, if checked. Again: For "all", if checked. Additionally it can create a DSK1.LOAD to show the contents of the disk and / or load and run the object file of the selected source. The "emulator" button starts the MAME emulator with the configured devices. If set up properly you might select "TI Extended Basic" from the master selection, get the disk contents displayed and after "please wait..." the compiled program should start. The "ADE" button is a shortcut: (A)ssembler, (D)iskManager and (E)mulator - all in one shot. So after editing / saving the source the test only needs 1) click on "ADE" button, 2) any key at the master title screen 3) "2" for XB, then wait... and enjoy! The menu at the top has no function as of now. The status bar at the bottoms shows info about running external tools to the left, "idle" to the right otherwise. Have fun! Michael

Hi, ralphb! I'm not quite sure, but... Those OPEN and INPUT comands are allowed only while running a program, not directly on the prompt. Line numbers... Michael

Just when you mentioned... Is there an easy way from changing disks from outside MAME? Right now I have to mount the disk(s) via the starting batch and then have to maneuver through the MAME menus to switch to another dsk file when needed. Thus I'm using empty dsk images for startup. When I store files on it I transfer (move or copy) them with Ti99Dir to other images after closing MAME. Unf. Ti99Dir doesn't seem to have acces to the mounted dsk files while MAME is still running. A tool like * ti-mount diskfile.dsk 2 rw would be great. Something the like around? Michael

HERO! After creating the "hash" folder and copying the ti99_cart.xml from my "large" MAME environment into the new one it runs instantly as expected. I was totally unaware of that file. Obviously having the PEB crowded with all that stuff _will_ decrease performance. It is just a batch giving me all the opportunities right now. It is not more like a "rem " in front of a line to deactivate unneeded components. And, in fact, it is only an extract from a much larger batch file that controls the existance of components, catridges and disks via command line parameters. Yep, I normally won't be using more than 2 disk drives and perhaps a hard disk. (I didn't have one that days. The ST-251 was the hdd in my first PC.) The RS232 is of no use for me and even the speech synthesizer will not be used in the near future. On the other hand I have read about RXB and SAMS and some other cool stuff I would like to know if they can be seen emulated in MAME. With my "real iron" that days I had a german 80-column-card (flat black case connected to the right side port, not within the peb). I hope the TI99_4ev is comparable to that one. Michael

Ah, and I should have added: The <project> folder must be created prior to calling the batch! Have a look at set xdt_drv=E: set xdt_dir=\Spiele\MAME\TI99\xdt99\ set xdt_prj=%xdt_dir%projects\ So I would have to MKDIR a project folder like E:\Spiele\MAME\TI99\xdt99\projects\graphics Probably a rem. > grf1.a99 in there, too, to create an empty source file. But that depends a bit on the editor used - how it complains about the "not existing" input file. And I like to have that batch as E:\Spiele\MAME\TI99\xdt99\xdt99.bat to have the projects folder directly beneath the compiler. BTW: The batch uses a "library" path for xas99 via set xdt_lib=%xdt_dir%lib\ Just in case you didn't notice... Michael

The usage of this batch is * xdt99 <project> [<source>] while <source> must not have an extension. The batch then initializes a lot of constants, some of them depending on the one or two parameters given. If you have a look at chapters (labels) param1 and param2: * If param1 <project> is not given then the batch ends instantly. Otherwise the %1 is stored in <ti99_prj>. * if param2 is not given then <project> is used as a base for the filenames <ti99_wrk>. Otherwise %2 is stored there. From <ti99_wrk> there are derived a few filenames for source, object, list, image, rpk and disk files. Given that you may have a project folder like "graphics" and work on a specific source "grf1.a99" within that folder by calling the batch with: * xdt99 graphics grf1 I would recommend to not use more than 6 letters for the source and not more than 10 letters for the project. Reason: I normally use the filename same as the "start" label and the project name is used as the disk-label (not the filename, but the label for the TI filesystem). Now the interesting part you have to adapt - chapter "settings": A lot of "set=..." for setting up the working directory / files (wrk), incorporating the cross-assembler and other external tools (xdt), the emulator (emu) and the like. This is the place where you will have to adapt one or another path and bin name. As you can see, the "windows" filenames are directly derived from <ti99_wrk> by adding .a99, .obj etc to the base. The "ti99" filenames are derived from the (uppercase) <ti99_wrk> by adding A, O etc. I normally separate file infos into <drive>, <path> and <file> to make moving the directory to another drive a bit easier. And then there is the big <emu> chapter that sets up the emulator, MAME in this case. Please note that there is set up a <flop1> with the disk for the Editor/Assembler and that <flop2> is REMed out - that one will be set later on. There are 4 loops following that you simply can ignore. They are a test for the project / file separation and I just happen to have them not deleted before publishing. What I will try to get: Albeit working on a specific source right now the (D)isk command shall copy other files from that "project" to the created disk, too. So if the project "graphics" contains grf1, grf2, grf3 and vdptools they all should be copied later on. The lifetime cycle of the batch starts at chapter "loop". After getting the user's choice it branches to the chosen chapter and hopefully executes the wanted tasks by using all that set up variables. (E)dit starts the external editor. I'm quite happy with NotePad++ although the syntax highlighting is not perfect. That d**n asteriks and greater-than characters always mix up with remarks, formulas and the like. Perhaps I have to always use ** for remarks and use blanks after the > operator to help with NP recognize them correctly. Nevertheless... If you start the (E)ditor the batch will wait for return from there, if... If you already have the editor opened then it will return instantly. I use this quite often to spare the (E) and work directly in the editor, save the file and continue directly with the (A)ssemble. For completeness I usually start creating (R)pk and (I)mage, too. Then The (D)isk has to be created and finally the e(M)ulator can be started. From the TI title screen a keypress leads to the menu where Editor/Assembler should be an option if nothing went wrong mounting the cartridge. From EA via option 3 "load and run" the compiled object code is found as DSK2.<ti99_obj> if nothing went wrong mounting the disk, too. If you are unsure about the exact filename just have a look at the last output from the batch: xdt shows the current directory of the disk. Have fun...

Hi, RXB! I just wanted to step in and say Cheers to you. I have read the whole thread and am impressed about the work you did. As a purist using only "stock" MiniMem, E/A and XB I never hassled thinking about "extended" versions for those cartridges that days. But your work reminded me of a (that days large and growing) collection of Assembler subroutines I've written for my convenience. A lot of functionality of your RXB mirrors what I missed in XB and scribbled together getting bloody fingers. If I see a way to get a cartridge in MAME format and mount it to the TI99_4ev I would really like to have a look at it. BTW: Your knowledge and interpretation of GPL seems very impressive, too. I had a look at GPL, I really tried, but never could get familiar with it at all. Michael