bjkrug

I don't have any background in pin-outs and how much current a circuit can handle, but this site claims that the Tomy Tutor cartridge address space was located at >8000. A lot of readers probably already know that the TI-99's cartridges were located at address >6000. So even if the cartridges were electrically compatible, and the Tomy Tutor could read the cartridge data, you'd have a bug at the first BL or BLWP instruction in the cartridge program.

@InsaneMultitasker One of side of the top cover does not latch properly, so I'll put either styrofoam or a piece of cardboard between the cover and the rest of the PEB. All the more reason for me to remove the cards during transit I guess.

I'm about to pack up a PEB so that a friend can sell it on e-bay. We're selling all of the cards and the box together. (Disk controller, 32K expansion, RS232 card) Does anybody have any advice on packaging it safely? I'm planning to remove the expansion cards, and put them in a separate package from the expansion box. I'm thinking I should leave the disk drive inside of the PEB, since it's fit pretty snuggly into the PEB anyway. I'll buy styrofoam to cushion the PEBs and use some left-over bubble-wrap for the cards. Does that all sound safe?

Exactly, those are margins. I'm not sure how to increase the user-friendliness without using up a lot of screen space. Unrelated, but here's an attached hotfix. There was a bug in screen-rendering right after switching from vertical-mode to windowed-mode. It was harder to reproduce in documents that have long paragraphs rather than short paragraphs, and so I couldn't see the bug often until recently. Here's also an Extended Basic program to convert Dis/Var 80 files to EmuWriter files. It's more limited than adding the same functionality to the assembly language program, but that feature is a relatively low priority for me: https://github.com/bkrug/Emu-Writer/blob/master/DisVar80toEmuWriter.bas EmuWriter.v0.2.1.dsk

There's no practical reason to use a TI-99/4a as your main word processing machine, but it still always annoyed me that most TI word processors are either apparent updates to TI-Writer or are very simple pieces of software designed to work on an un-expanded TI. I don't wish to imply there is no place for that, but I decided to see what else I could come up with. Emu-Writer is a designed to be different more substantially different from TI-Writer, but to still be something a software publisher could reasonably have distributed in the early 1980s. https://github.com/bkrug/Emu-Writer To load the program file, enter E/A 5, and type DSKx.EMUWRITER. You will find two example documents on the disk, with the file names HANSEL and THREELANG. Emu-writer distinguishes itself from TI-Writer with the following featues: When you wish to insert text into the middle of a paragraph, just move the cursor to the desired location and start typing. No need to press FCTN+2 followed by CTRL+2 FCTN+3 is used as a backspace-delete key. FCTN+0 is used to switch between Vertical mode and Windowed mode. Windowed mode works the same as TI-Writer; when paragraphs will be more than 40 characters wide on paper, it is necessary for the screen to move to the left or right within a page. Vertical mode assumes that a user wants to read text from the screen. On screen, the wrap algorithm assumes a paragraph width of 39 characters, even though the printed document will have wider paragraphs. It is not necessary to switch modes before printing. The print algorithm automatically wraps the paragraphs for 80-columns. I realize that this is possible in TI-Writer, but that program makes it less intuitive. The user has to know how to wield the Editor's margin-and-tab configuration in a way that is complemented by the Formater program. When I named EmuWriter, I think I was thinking of emus, the bird. Something about this one picture of an emu has always amused me. But it's also convenient that most people who try this software out, will do so from an emulator. Attached to this post is v0.2 of the word processor. EmuWriter lacks the following features before I would be comfortable labeling the release 1.0: Page Up/Page Down Cut/Copy/Paste Undo/Redo Find/Replace the entire upper 24KB of the memory expansion is reserved for the user's document, but the user will struggle to create a document of more than about 16,000 characters. EmuWriter.v0.2.dsk

On the one hand, the files I've tested with so far haven't had a division higher than 24. So it's possible that the current code just isn't handling high division values well. That being said, after reading your comment, I wrote a unit test in which the divisions value is 120, and it passed. Keep in mind that for the output assembly language file, a quarter note is always represented with a value of 24. If the <divisions> tag specifies 24,000, the parser (in C#) will divide quarter-note-durations by 1,000 using the below code. The variable lengthOfQuarter holds the value found in the <divisions> tag. This comes from NoteToGeneratorGrouper.GetNotesForOneToneGenerator(). Duration = (Duration)((double)Duration.N4 / lengthOfQuarter * duration) One issue that could come up in the future is notes longer than a double whole note. The assembly language output represents durations as bytes. Since 24 represents a quarter note, we can represent a double whole note as 192. I haven't written anything to deal with non-rests that are longer than that. A bug would probably result from a song with a triple whole note or a set of tied notes of such a length. Another problem is that I now see that the MusicXml format allows different musical-parts to have their own <divisions> tag. If we find a MusicXml file where different parts have different divisions values, then the current parser will incorrectly apply the first divisions value to all of the parts.

If the two quarter notes are the same tone, and there is no pause between notes, then the quarter notes blur together as a half note. In the above cartridge program, listen to "Turkey in Straw", and hear how different it sounds between envelopes A & B. Envelope A has no pause between notes, but envelope B does have pauses.

I’ve been working on my own MusicXml parser (https://github.com/bkrug/envelope-demo#readme). As stated in the Readme the parser supports: Storing a separate stream of data for each tone generator Repeats and volta brackets compressing rests to save space storing notes as 7-bit values instead of 10-bit values An accompanying cartridge program plays the output, and also demonstrates adding envelopes to music auto-detection of a 60hz vs 50hz environment playing music at different tempos as specified in a song header I'm not the first person to create a MusicXml parser for TI-99 development, but I think existing parsers are geared towards sound lists. The reason I prefer to have a separate stream of data for each generator, is because that way I can support, for example, a half note played simultaneously with two consecutive quarter notes. My parser is shared as source code, because while another developer could use the compiled parser as is, it's also likely that one would want to add features I didn’t add. For example, the parser doesn't currently support dynamics. The existing repo has high test coverage, so you should be able to add functionality without breaking something you didn’t mean to. MusicEffects.rpk musiceffectsC.bin MusicXmlParser.exe

Here's one more. It's more of an XB demo disk, but it includes some Sci-Fi theme songs. SpaceShuttle.dsk

I realize there is already a thread on Sam Moore music (https://forums.atariage.com/topic/301740-sam-moore-music-list/#comment-4454902), but I have some disk images that are more generic, in that they are by more than one author. I just made these images recently from disks at my parents' house. Is there a better place to post stuff like this than in a forum? For instance, does http://ftp.whtech.com/ take submissions? C-Series Vol.1.dskMusicDemoDiskSide1.dskMusicDemoDiskSide2.dskSingingTiDemo.dsk

Mocking data in assembly hasn't been a lot harder for me than mocking data in C#. Mocking routines could eventually get hairy; I've only had to do a little bit of that so far. If a mocked routine is supposed to return different values under different circumstances, then something needs to be done in the Arrange portion of the test to specify that. That can sacrifice legibility. And, yeah, I'm writing tests for memory management and array algorithms. If I were writing a game, my test coverage would be way lower, if not zero. As far as I know, modularizing code enough for unit testing could impact game performance.

Does anyone here write unit tests for your Assembly Language projects? What is your preferred coding format for doing so? The below is my approach. ARYINS is the routine being tested. AEQ and ANEQ stand for "Assert Equal" and "Assert Not Equal", respectively. They are comparing the contents of R0 and R1. * * Insert an element at the middle of * an array. * Grow array and move it. * No empty block follows the original. INS5 * Arrange LI R0,INS5Y MOV R0,@BUFADR LI R0,INS5Z MOV R0,@BUFEND * Act LI R0,INS5X+2 LI R1,3 BLWP @ARYINS MOV R0,R9 MOV R1,R10 * Assert LI R0,INS5X+2 MOV R9,R1 BLWP @ANEQ TEXT 'Array should have moved.' BYTE 0 EVEN * MOV R9,R0 AI R0,4+12 MOV R10,R1 BLWP @AEQ TEXT 'Element address should be ' TEXT 'directly after the third ' TEXT 'element.' BYTE 0 EVEN . . . RT