Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Days Won


Blog Entries posted by OLD CS1

  1. OLD CS1
    There is plenty of music and sound effects available for download in the VGM format for the SN76489 PSG (programmable sound generator,) a cousin of the TMS-9919 sound generator in the TI-99/4 and 4A computers.  For a while I have enjoyed working with the sound list format played by the 99/4's ISR (interrupt service routine) as defined in the Editor/Assembler manual.  It is a simple format defined in rows or frames, each containing a number of bytes sent directly to the 9919, and each row may have a duration (or delay until processing the next row) from 1/60th of a second to 255/60ths (roughly 4.25 seconds.)
    The format is well-defined in the E/A manual, and suffice to say, each row looks basically like below, and a song is terminated by a row with duration of >00.
    x { y } z BYTE >06,>8E,>0F,>93,>AC,>1F,>B3,>28 Where x is the number of bytes to send to the 9919, {y} is the set of bytes to send, and z is the duration of this row or frame in 1/60th second jiffies (or 1/50th for PAL consoles, as it is timed by the vertical blank.)
    This script will take a VGM file for PSG and convert it into a binary containing an equivalent ISR sound list.  It is an oafish and ham-fisted way to do it, but it works and most lists output can be loaded by SoundListRipper for review, editing, or conversion to Extended BASIC statements.  The caveat here is vgm2isr does no processing of the VGM, so fancy things like frequency sweeps may produce binaries which cannot be loaded in SLR, and loops are ignored.  It cannot produce usable output of pseudo-PCM encoding nor VGMs with timing which differs from 50Hz or 60Hz frame-rate.
    This script requires Regina Rexx or compatible.  While it was originally written to work in ARexx, I can no longer guarantee it runs on an Amiga as my system has been non-functional for a while.
    In Amiga parlance, the command template is
    vgm2isr FILENAME/A,TO/K,NF=NTSCFIX/S,D1=DEBUG/S,D2=DEBUG2/S,BYTE/S,V1/S Or for non-Amiga types
    vgm2isr.rexx <filename> [to <filename>] [{nf|ntscfix}] [{d1|debug}|{d2|debug2}] [byte] [v1] nf or ntscfix will brute-force a PAL VGM into NTSC timing by inserting an additional jiffy every four (or add 1/60s every 4/60s.)
    byte will output a list of assembler BYTE commands of the ISR list, one BYTE command per row.
    to followed by a filename will over-ride the default output filename which replaces .vgm with .bin
    v1 forces VGM file recognition as under v1.50 (see notes below)
    The two debug levels output information as the VGM is processed.
    Do not use filenames or paths with spaces.
    vgm2isr.rexx help or just the command with no arguments will display command template and example.
    Just remember, the ISR sound list format is not optimized.  Long songs can be ridiculously wasteful of memory.  It works just fine for short songs, fanfares, sound effects, interludes, &c.  But level background music (like Sonic the Hedgehog) can easily take up most or all of cartridge space memory.  There are better tools for such work, like the VGM Compression Tool.
    Notes on current version:
    Not all debugging is enabled or in place -- currently just identifies the VGM header version. Byte output does not prevent binary file output. Syntax checking is not complete and could over-write your source file if you are not careful. v1 switch is added to deal with v1.50+ VGMs in which the commands do not start at 0x100. This may be my misreading of the spec, but if a conversion is missing some leading data in the output and debug shows v1.5 VGM or later, try the v1 switch. ISR output is not optimized: commands and rows may be repeated unnecessarily.  
    Priority to-do:
    Some game systems use a different timing for generator 3 modulated periodic noise, so the output will be a semi-tone off. (The fix is currently part of my personal sound_list.rexx manipulation script.) Dual-channel PSG support. ISR output optimization.  
    Example of the v1 switch, see the included "madness2.vgm" and two output files, "madness2.bin" and "madness2_v1.bin". Other working examples included are inchworm.vgm song, and powerup6.vgm sound effect.
  2. OLD CS1
    I got hold of a neat little GGI Gear CT2DG tape-to-MP3 recorder, purchased from a fellow AtariAger, to see how it might replace my setup of a real tape deck and USB audio capture device.  The name is a misnomer as it shows up to Windows as a generic USB audio device, which means you can use your favorite audio capture software and are not relegated to a compressed capture.
    I used my master tape of Laser Strike for TI BASIC as the test subject*, Audacity v2.3.2 to capture the input, and CS1er v0.96b to convert and @Tursi's Classic99 v399.050 to import the captured audio.
    The volume control on the CT2DG controls the on-board monitor (headphone jack,) as well as the volume of the captured audio.  I turned this up to maximum without any perceptible distortion, though you can see the clipping of the start of the sync header.  Audacity's recording level was set to 3 -- this is important as a higher setting would have caused much greater clipping at the sync.  Audacity faithfully captured the audio, including leader noise and the initial volume spike of the sync stream.

    Leader noise, sync with volume spike, and start of data as captured.

    Tail of sync and start of data at 14.19 to 14.23 seconds. A nice clean and consistent capture.
    Once captured, I used the leader noise in the first ten seconds or so of the recording to train the noise reduction filter, then ran that against the entire capture.  Then the limiter was applied to the volume spike at the beginning of the sync.  I then amplified the capture by -2dB, raising the peak to around .85 on the scale.  The capture was exported to a 16-bit WAV.
    CS1er requires a mono 8-bit WAV for input, so I converted with this command:
    ffmpeg -i laserstrike.wav -c:a pcm_u8 -ac 1 -y laserstrike_mono8bit.wav Running the resulting file in CS1er resulted in a long string of errors and rejected records.  I went back and tried the raw capture as well as the capture with noise reduction but no volume manipulation, to no avail.  Classic99 refused to pull any data from the 16-bit stereo exports.
    Although the Classic99 manual only states the requirement of a 16kHz or higher WAV file, with no apparent restrictions on sample width or channels, I finally focused on the 8-bit samples to see what Classic99 would make of them.  Contrary to before when Classic99 would not read the 16-bit stereo WAVs, it processed the 8-bit mono WAVs perfectly.  This included the initial raw capture with no manipulations.
    For this exercise, Classic99 wins the day.  In the past I could have spent immeasurable time with CS1er, or even Tape994A, to try get a good read.  I am happy to have another tool in my belt, weapon in my arsenal, arrow in my quiver, to help with future conversions.  As well, the GGI Gear CT2DG has proven itself to be a compact contender to the space-consuming tape deck setup.  While this restoration was on a much cleaner source than many others I have taken on, the process bodes well as a first-approach option.
    * Recorded on a genuine TI Program Recorder from an authentic TI-99/4A console onto a Maxell CP15 "Personal Computer Cassette."
    The primary tested WAV files, manipulated and raw, are attached below.  The Audacity project is too large to include.
    Laserstrike CS1 Restore Test.zip
  3. OLD CS1
    The APC BackUPS Pro 1500VA UPS, model BR1500G, has an external battery port on its back.  This port is interfaces with the BP24BPG, which is a 24V external battery pack holding four 9Ah or 7.5Ah 12V sealed lead-acid (SLA) batteries.  These batteries are identical to the two which are in the UPS, itself, but in 2x2 series-parallel configuration, giving 24V.
    The external battery pack looks like, is the same size, and costs just as much as the UPS: $180 new from APC and most retailers.
    For anyone who works with the APC SC-series UPSes and has replaced those batteries, this port will look familiar.  It is physically compatible with the plug on the RBC-33, which is two batteries strapped together in series using the 870-2183(a) harness.  In fact, it is the identical plug used to connect the BP24BPG external battery pack to the BR1500G.  However, plugging the RBC-33 into the external battery port does not give any results as the UPS simply ignores the battery pack.
    Examination of both the port and the plug reveals three connectors.  Obviously two are for the positive and negative terminals of the batteries.  As both the BP24BPG and RBC-33 are 24V packs, it was fair to consider the third connection could be a "sense" line with some value of resistance to indicate the unit's purpose.
    Taking a look at the 870-2183 harness proves this idea out, showing the heavy gauge black and red wires, and smaller gauge yellow wire coming out of the cable into the plastic bracket which holds the two batteries together.  There is also a short heavy gauge yellow wire which jumpers the negative and positive terminals of the batteries.  This configuration puts the batteries in series for 24V output.
    Fortunately, I did not just jump on the idea of the sense line being some level of resistance.  It terminates directly on the positive connector, putting a full 24V down that line, which could have blown my ohm meter right out.  Here you can see the yellow wire routed on one side of the plastic bezel of the RBC-33, then on the other side where it is crimped right into the positive connector.
    At the plug, the wires in the cable match up to the three "prongs" exactly as they run in the cable.  This plug is marked with each connector's polarity.  The multi-meter confirms there is no resistance between the plug end of the yellow wire and where it terminates at the positive battery terminal.  But this still does not answer the question of, why does the UPS not recognize this as an external battery pack?  What does the BP24BPG do differently?  It cost me $160 plus shipping to find out.  Following the same reverse-engineering procedures on this pack as on the RBC-33, I found the connector uses the same polarity and the sense line is grounded instead of connected to the 24V positive.
    This is an easy enough modification to make: simply move the sense wire to the negative terminal on the RBC-33 battery pack's 870-2183 battery harness.  Once connected to UPS, the UPS makes a "beep" to indicate it recognizes the external battery.
    APC advertises the battery pack as tripling the run-time of the UPS.  This makes sense as it does triple the number of batteries connected to the unit: four external and two internal.  Using the modified RBC-33 only adds two external batteries, which should give double the run time.  This is bore out in testing by changing the external pack in use on a UPS under load.  While running my chest freezer, the UPS shows 114 minutes of run-time available.  With the BR24BPG connected that run time increases to 338 minutes, and with the modified RBC-33 connected the UPS reports 232 minutes.
    I had concerns about how the UPS would behave charging just two external batteries rather than the proper four, so I ran the unit supervised for three days in this new configuration.  I found it does properly manage the two external batteries.
    Though the connecting cable is shorter, this modification is a viable alternative to much more bulky full battery pack.  The harness can be found inexpensively on its own from various sources, including some local battery stores, making it economical and perfectly usable.  Even buying a new RBC-33 is half the price of the BP24BPG, commensurate with the extra run time provided versus the full pack.  I have several of the harnesses around, and this low-cost alternative will be very handy during the next extended power outage from a storm or hurricane.
    UPDATE: At the time I posted this, the UPS in question had been running for two weeks with the modified RBC-33 attached.  Today it started running its fan constantly.  The only relief is to remove the battery pack.  Not certain what is causing that, or if the behavior is isolated to this UPS.  It could be the self-test is detecting the unauthorized pack.  I will have to test out another UPS and see if it duplicates this behavior.  If so, I might be able to get it to "tell" me what is wrong.
    The fan did eventually stop.  Again, not sure why it started up, but it seems perhaps it was giving a charge to the battery.  I noticed the UPS with the BP24 acted similarly after having run on battery for a minute.  The modified RBC-33 still works out to be a good configuration.
  4. OLD CS1
    TI BASIC built into the TI-99/4A console is slow.  Really slow.  This lack of speed hampers a lot of good game development for console BASIC.  Not impossible, mind you.  Many game makers working in TI BASIC have found ways to work with the lack of speed while still maintaining a functional game.  As well, players generally get used to knowing they have to hold a key down or joystick in the direction until the magical moment the program is able to run the detection.
    For my purposes, I need to detect several things as quickly as possible and ideally in the same subroutine.  I need to detect joystick (cardinal directions,) "arrow keys," fire button, function (FCTN) key presses, maybe other keys.  This is a lot with which to deal: a joystick, a special key unit for the arrow keys, and another key unit for other key presses.
    Thus: the UserInput subroutine which is present in my two BASIC games released on AtariAge in the TI-99 subforum, though more refined here.  The routine will return values in J={0..5} for nothing pressed, left, right, down, up, and fire, and optionally {6..} for FCTN keys.
    UserInput is not a general-purpose input routine, but is specifically tailored to return cardinal directional presses of the joysticks, fire buttons, equivalent key presses, and optional FCTN keys.  It is presented here in TIdBiT, a pre-processor by Matthew Hagerty @matthew180 for writing more structured programs in TI BASIC and TI Extended BASIC.  The source at the bottom of this post can be used in your own programs and translated at https://tidbit99.com.
    UserInput requires three entrance variables.  First, P for player number, negative if only scanning the joystick.  In my games I use P to track player number so this tracks itself.  However, if wanting to do something fancy which the routine will allow, your program could use another variable to track the current player and then put the appropriate value of {1, 2} or {-1, -2}.

    What happens with these values of P?

    P={1,2}: scan split keyboard and joysticks, fall-through to scan unit 3
    P={-1,-2}: scan joysticks, fall-through to scan unit 3

    Effectively, a negative value for P indicates to only scan the joystick for direction, ignoring split-keyboard mode presses (units 1 and 2) including the fire button (so be careful with this.)
    Next is K$(0), which contains the key codes for left, right, down, up, and fire.  For the default sense, this is the values 2, 3, 0, 5, and 18, for the keys "SDXEQ" for scan unit 1 and "JKMIY" for scan unit 2.  (See User's Reference Guide page II-88 or page 204 of the TI Extended BASIC manual.)
    The last required variable is K$(1), which holds the alternate fire button key (required, generally the space bar,) and any optional function keys per keyboard scan unit 3, in the range {1..15}.  (See User's Reference Guide page II-89 or page 199 of the TI Extended BASIC manual.)  In my games I use this to define FCTN keys, like AID, REDO, and BACK, where these FCTN keys will return 6, 7, and 8, respectively.
    As mentioned above, this is a little more of a trick hidden here.  The -P for joystick-only scanning is a bit of a fib.  If a joystick scan does not return on of the four cardinal directions, the standard keyboard is still read.  This makes the routine still useful for detecting FCTN keys.  Since keyboard scan unit 3 is in use here, only upper-case and FCTN keys are available.  The scan unit can be changed to 4 (Pascal) or 5 (BASIC) if desired for whatever purpose, and K$(1) set accordingly including those which would conflict with the split-keyboard codes.  Character codes in K$(1) will return values of {5..x}, where x is base of 4 plus the length of the variable.  This, however, goes well beyond the purpose of the routine and would be more complicated than necessary.
    (The listings below includes simple modification to make K$(1) not require the alternate fire key and make the return {6..x}, where 6 is the first character of K$(1).)
    K$(1)=" "&CHR$(1)&CHR$(6)&CHR$(15)
    With variables set as required, your program will call the subroutine with
    GOSUB UserInput
    The flow of the TI BASIC version is below to demonstrate operation.  It starts with quick house-cleaning and check the detection type wanted:  Clear J, the return variable, and see if the player number is negative which indicates to only scan the joysticks.
    UserInput: J=0 IF P<0 THEN JoyStickInput
    If the keyboard is to be scanned, scan the unit number of the current player.  Jump to scanning the joystick if no key is pressed.  If a key is pressed, then decode for a valid value from K$(0).  If valid, return to the calling program, otherwise we know a key not joystick-related is pressed so it needs to be checked against standard keyboard scan unit 3 and K$(1) (the jump to KeyScan.)  This introduces a bit of a race condition here, as it is possible the user can press a key and get caught by the split-keyboard scan but release it before the standard scan.
    CALL KEY(P,K,S) IF S THEN UnitKeyPress ELSE JoyStickInput UnitKeyPress: J=POS(K$(0),CHR$(K),1) IF J=0 THEN KeyScan RETURN
    At this point since no split keyboard unit has been pressed, or P is negative, then the joysticks are scanned.  CALL JOYST (User's Reference Guide page II-90, TI Extended BASIC manual page 109,) returns two values in the set {-4,0,4}.  This check is logically (X OR Y), meaning if the joystick is pressed in any direction.  As this routine is only concerned about cardinal directions, the mathematical result of X+Y also has the logical benefit of ignoring two of the four ordinal directions to be filtered in the next check.
    JoyStickInput: CALL JOYST(ABS(P),X,Y) IF X+Y THEN JoyPress
    If no joystick press is detected, fall through to CALL KEY keyboard scan unit 3, validated against K$(1).
    KeyScan: CALL KEY(3,K,S) IF S THEN KeyPress ELSE ExitInput KeyPress: J=4+POS(K$(1),CHR$(K),1) // Change to J=5+... to skip a fire-button alternative key, // but note Q and Y will still be detected as fire buttons  
    Next is the main exit and return for the input routine.  At this point J should contain a valid key-press validated against K$().  Anything else is rejected.
    DecodeJoySt: J=J*-(J>4) // Change to (J>5) to skip alternate fire key-press (Q,Y still detected as fire) ExitInput: RETURN
    The last bit of decoding eliminates the remaining ordinal joystick directions using X*Y (X AND Y in Extended Basic) which were not filtered previously by X+Y.  Logically, (X*Y) is (X AND Y), which means this detection is rejected if a the joystick is pressed in both an X and Y direction.  The second part now turns X{-4,4} or Y{-4,4} into the values {0..4} corresponding to none (which should never make it here to be detected,) left, right, down, and up, by way of a somewhat convoluted formula (likely the cause of the slower response to joystick than the keyboard) which produces the below value table for the valid values of X and Y.  The routine then returns from here.

     X  Y  J
    -- -- --
    -4  0  1
     0 -4  3
     0  0  0
     0  4  4
     4  0  2
    JoyPress: IF X*Y THEN DecodeJoySt J=ABS(((SGN(X)+3)/2)*SGN(X))+(ABS(((SGN(Y)+3)/2)*SGN(Y))-2*(Y<>0)) RETURN  
    Notes on UserInput subroutine variable usage:
    Requires: P, K$(0), K$(1) as described above Uses: X, Y, K, S Returns: J Obviously these variables can be changed as seen fit.  For additionally sorcery, K will contain the key code of the last key detection.
    Label usage by UserInput subroutine:
    UnitKeyPress JoyStick KeyScan (not in TI Extended BASIC version) DecodeJoySt JoyPress  
    While working on this post I had a few ideas
    I should elaborate on the X,Y to J conversion formula.  Perhaps in a later post. There is a possible opportunity for some change in flow which may or may not help with additional optimization.  As it is, the routine is pretty fast though there is a noticeable but negligible slower response to joystick than keyboard. Using K$(0..1) is not memory efficient as, by default, an array is allocated with 10 elements.  Thus, program memory footprint and variable stack usage may be reduced by using something like K0$ and K1$, or maybe more by using appropriately-named single-character string variables (perhaps [$ and ]$ for fun.) In the TI Extended BASIC version, several changes were made to logic and combination of lines into multi-statement lines. The TI Extended BASIC version contains some logic changes made to favor execution speed.  For instance, the statement IF S THEN (next line) ELSE RETURN is faster than IF S=0 THEN RETURN by a difference of 15 seconds over 10,000 iterations.  

    TIdBiT source of the full routine for TI BASIC
    UserInput: J=0 IF P<0 THEN JoyStickInput CALL KEY(P,K,S) IF S THEN UnitKeyPress ELSE JoyStickInput UnitKeyPress: J=POS(K$(0),CHR$(K),1) IF J=0 THEN KeyScan RETURN JoyStickInput: CALL JOYST(ABS(P),X,Y) IF X+Y THEN JoyPress KeyScan: CALL KEY(3,K,S) IF S THEN KeyPress ELSE ExitInput KeyPress: J=4+POS(K$(1),CHR$(K),1) DecodeJoySt: J=J*-(J>4) ExitInput: RETURN JoyPress: IF X*Y THEN DecodeJoySt J=ABS(((SGN(X)+3)/2)*SGN(X))+(ABS(((SGN(Y)+3)/2)*SGN(Y))-2*(Y<>0)) RETURN  
    TIdBiT source of the full routine for TI Extended BASIC
    (Translates to seven lines of Extended BASIC code.)
    UserInput: J=0 :: IF P<0 THEN JoyStick ELSE CALL KEY(P,K,S) :: IF S THEN UnitKeyPress ELSE JoyStick UnitKeyPress: J=POS(K$(0),CHR$(K),1) :: IF J THEN RETURN ELSE KeyScan JoyStick: CALL JOYST(ABS(P),X,Y) :: IF X+Y THEN JoyPress KeyScan: CALL KEY(3,K,S) :: IF S THEN J=4+POS(K$(1),CHR$(K),1) ELSE RETURN DecodeJoySt: J=J*-(J>4) :: RETURN JoyPress: IF X AND Y THEN DecodeJoySt ELSE J=ABS(((SGN(X)+3)/2)*SGN(X))+(ABS(((SGN(Y)+3)/2)*SGN(Y))-2*(Y<>0)) :: RETURN  
  5. OLD CS1
    I pre-ordered my The C64 Mini from WalMart and it arrived on October 9, which I picked up a mere six hours before the store closed in preparation for Hurricane Michael which would arrive the next day. As a result, my time with the new goody was pushed back over a week.
    But I have now had a chance to spend a few hours every day or so for the past week and a-half and am happy to present the results of my fun and hard work putting this all together.
    (User @wongojack has a great post with some tips for sourcing and managing disk files here.)
    The Dressing
    With many things, the packaging is the first and most important part of a product on a shelf since it more often than not what the prospective buyer see first in the store, and what the buyer sees first when it arrives in a plain brown box.
    Eh, not too shabby on the shelf.
    Then comes the obligatory un-boxing. (Quick aside, these photos are places two-by-two, so you may need want to widen your window or set your zoom so save you scrolling so much -- provided you can still read the text.)
    First sitting on my flux-stained soldering bench. It did not occur to me until later I should be doing this without the board in place. (I am not professional reviewer, after all, and I hope that fact also wins me forgiveness for the color and lighting imbalances in the photos.) Here you can see the intact seal on the box to validate this is, indeed, a virgin product.
      Break the seal and open 'er up, nice and gently, now.
        Nice packaging on the shelf, and the inside does not disappoint, either. Not quite the "Welcome to the World of Commodore" to level-up to a Mac or my old Sony Ericsson boxes, but still teases a little more as to the wonders which wait within.
        Pay dirt and, again, not too shabby. Presentation here is clean and crisp, and the extra mile of clear plastic protection to ensure there are no scuffs or marks as the "product may settle during transport." Little I hate more than spending a pretty penny on something cool to find it has box bruising.
        But, like so many good products -- the printer or scanner lacking a USB cable, for instance -- the package complete with quality HDMI and USB cable does not contain a USB power adapter, quality or otherwise. Now, while the argument may go, "everyone has one or two laying about," my counter is far too many are cheap and may not stand up the voltage to the power draw, or may even reference ground signals right to your outlet power thanks to cheap design. For the $79 price tag I would think including a manufacturer-approved power supply would be a given.
        USB power source notwithstanding, it does come with a nice-looking Commodore-esque instruction manual.
    Under the Dressing
    Past the outer layers is the first opportunity to observe the superficial presentation of the product body. First and foremost is enumerating ports and how to actually use the device.
    Simplicity is the key, with HDMI video output, micro-USB for power, two ports to accept accessories via USB, and one button to turn it on. Note the USB ports are upside-down due to the internal mounting of the system board.
    Closer examination of the detail and the best thing I can say is, wow. It is obvious a good amount of thought went into this design. Without calipers one can quickly determine this is a near-exact replica of our beloved brown bread-bin beast, right down to the texture of the clamshell.
    The correctly sized badge with product-specific design, and the brightness of the LED bolster the relationship to the original.
      The keyboard looks near-perfect except for the glaring omission of the print screening on the key fronts -- no special characters nor even-number F-keys. But, the impersonation of the original is so good that, especially out of the corner of the eye, THEC64 Mini is easily mistaken for the old gal.
    In the Living Room
    Having taken in the sights of the new lady in then out of the dressing and assessed how to play, the next logical step is to evaluate the play. I suspect the majority of those who will bring her into their home are not too concerned about her language skills, so I mainly focused on game-play and accommodation thus.
    First thing to address is the joystick. I have never been a fan of the Competition Pro, though it apparently has an almost cult-like following. As the design of the C64 Mini is closely linked to this rather crafty eight-button rendition of the classic, I am stuck using it to some degree rather than my preferred Atari CX-40 style of joystick.
    In testing I was happy to find my trust old Gravis Gamepad Pro works perfectly fine for games. As indicated in the documentation, the start button acts as the menu button and other buttons simply fire. The arcade-style controller for my NeoGeo X Gold which works perfectly with Windows does not work here. When two joysticks are connected the C64 Mini does a really smart thing: whichever joystick is used to navigate the menu becomes the primary joystick which is always Joystick 2. More about that below.
    The Games She Plays
    The C64 Mini comes loaded with 64 games listed on the official website and includes manuals for each. Suffice to say, there is a mix of games in the North American release which may or may not be recognized by U.S. players. I do not see this as a problem, really, as you will get games you like, love, and new ones to try out.
    Navigating the menu system is easy, painless, and intuitive, and navigating once inside a game is simple, too. Pressing the menu button on the joystick brings up the in-game control menu to save/load a saved game state, call up the virtual keyboard, or exit the game.
    In-game control menu
    The system provides four save slots for each game. The virtual keyboard is another clever feature which slides in from the right-side of the screen, pushing the video over to the left, taking advantage of the space "wasted" by a square video display view in widescreen. It is responsive and does not take terribly long to type in what you might need in a game, though I would not recommend this over a real keyboard for programming in BASIC. Several of the red buttons are given functions in the virtual keyboard, such as SPACE, ENTER, and backspace/delete, while the menu button hides the virtual keyboard. The keyboard is divided into three blocks of alphanumeric keys, symbols, and special and function keys, with a red button to jump between these blocks. Much quicker than pressing the joystick a million times to get to that odd key. My only lament regarding the virtual keyboard is the special buttons for ENTER and SPACE are not activated until opening the virtual keyboard.
    THEC64 MIni virtual keyboard. (AA editor lacks a way to align text around a graphic.)

    I started with the most recent firmware release to date, v1.1.4, available from the website update section. Firmware updates are ridiculously simple to apply when needed, and this update includes the File Loader, a promised addition to allow easier running of games from a USB flash drive. File Loader is accessible via the icon which looks like a USB stick in the icon dock at the bottom of the screen.
    Menu icon dock: screen settings, about, settings, and file loader.
    As the system is built from Vice, confirmed by scrolling through the licensing information which apparently comprises a bulk portion of the 3.5MB firmware image, one would and can expect vast compatibility for games and programs.
    The File Loader is compatible with D64, G64, D71, and D81 disk images, T64 and TAP tape images, PRG and P00 program files, and CRT cartridge files. My testing included D64, G64, T64, and PRG files with minimal fuss and no incompatibilities.
    The system has, by default, disk acceleration which makes loading games much faster than in real life. This can be turned off for compatibility purposes. The acceleration also appears to have influence on tape loading. I did not test for compatibility with commercial tapes and fast-load tapes as I am unfamiliar with this facet of Commodore life. The single T64 image tested was Laser Strike, a COMPUTE! Magazine type-in BASIC program, which loads and runs with no problems.
    More Than Just a Pretty Face
    Indeed, the File Loader has a lot more features under the hood as explained on the website. I will not be delving into the deep details of the extremely powerful CJM files which allow detailed configuration right down to the special buttons. In fact, I only investigated this as I was having problems with some programs running at all. Ballblazer, a G64, would not load at all, nor would Ghosts 'n Goblins Arcade or several of the demos on D64.
    File names on the USB stick can include settings options which are demarcated by a "_" as the end of the filename, before the extension. For example, to get Ballblazer to load I renamed Ballblazer [NTSC].G64 to Ballblazer [NTSC]_AD.G64 to activate "accurate drive" mode and it fired up and played like a champ. Accurate drive mode is exactly as it sounds: an accurate emulation of the 1541 disk drive to support programs which rely upon its functionality. Enabling accurate drive mode also enables a flickering floppy icon in the upper-right of the screen to show when the "drive" is being accessed.
    Demos which would not function properly were fixed with the "TP" option to set PAL mode. PAL mode also fixed Frogger Arcade Edition and allows for the excellent Yoomp! Video captures indicate the output changes to 50Hz when in PAL mode.
    Lastly, the C64 Mini assigns the primary joystick as port 2. Familiar to all of us is the frustration of single-player games which eschew this standard. Welcome the "J1" option which changes the primary joystick to port 1, which then resolved problems with those games which expect a joystick in port 1, like Blackhawk, Arkanoid, Satan's Hollow, and others.
    Thus, after making the necessary filename changes with the "AD", "TP", or "J1" options I happily found myself with a full complement of usable games and demos on my USB stick.
    Rather than lengthen this entry even more with videos, check them out in my gallery dedicated to the THEC64 Mini, recorded with video in "Pixel Perfect" mode.
    The only major shortfall I see off the bat with the File Loader is it only supports a single disk at a time. This means you will not be playing the eight-sided adventure of Pool of Radiance or the flippy Last Ninja. You need a keyboard for the latter, anyway, but we have that covered below. Swapping disks is currently possible, as detailed in the troubleshooting section, but doing so requires loading games via BASIC and using a special disk image naming scheme and game saves. A better method is promised for a future firmware update:
    I hope to see a "swap disk" option in the in-game menu which would then lead to the File Loader to select the next disk.
    I will not go over the built-in games any more than to say they play well and the ones I recognize play just as well and are still just as fun as in the old days, or just as frustrating in regard to Coil Cop. At least two of the included games are obviously modified for the C64 Mini. Specifically, Cybernoid has been updated to remove the option to use the keyboard as a controller:
    Original release on the left, showing options 2 and 3 for keyboard controls, C64Mini release on the right missing these options.
      The website also notes other games may have been modified to fit the new form-factor, but the modifications do not substantially alter or affect game-play.
    I tested a few different USB sticks, ranging from really old Sandisk 1GB sticks, a 4GB promotional key-shaped stick, a 128GB Samsung USB3 nano, and finally resting on a Sandisk 32GB nano. All worked perfectly fine with no hiccups.
    The manual indicates that if you need more than two USB devices you should use a self-powered USB hub. Sage advice, though I did not follow it. I used an inexpensive Manhattan 4-port USB2 mini-hub to connect a standard Logitech keyboard, the THEC64 joystick, and a often a second controller. This worked fine and I give more details below on the power draw. Make certain that your hub is plugged in before applying power or it may not be recognized.
    While disappointed, I was not surprised to find this configuration would not work:
    XU1541 USB to CBM serial with a 1541-II disk drive... no worky, but perhaps one day?
    Since the C64 Mini comes without a manufacturer-approved USB power source, we are left to experiment with our own. I have a two-port USB power supply built into a three-outlet station which powered this just fine. So well, in fact, I also used the other USB port to power a 5-inch monitor, the Eyoyo S501H. Together idle, the pair draw around 430mA, and when playing I would see jumps up to 560mA, most of the delta drawn by the monitor speaker.
    Having an all USB-powered portable Commodore 64 in enticing, and the low power draw means a good battery pack should be fine. I pulled out my Anker PowerCore 26800 three-outlet 26,800mAh power pack and gave them a whirl, the monitor plugged in directly so I could monitor the C64 Mini and its accessories alone. Great success! So what about other battery packs? I happen to have a few clearance USB batteries to try out. These held up, as well, with the only one to not dip below 5V being the cheapest of them all. Impressive, even if the smaller packs will be far more short-lived at a rated capacity of 2200mAh and a measured capacity of around 1750mAh.
    The Anker running a game of Space Taxi
    The best and worst voltage levels from the Anker while in use, the C64 Mini measured alone
    The cheap-o USB battery packs get to play, too.

    What's in the Box?!
    This part is just pictures of the inside of the C64 Mini. Noteworthy points are the three large metal weights to give it a little heft. These are Bucky Ball confirmed to be magnetic but not magnetized.
      I suspect the chip under the metal heatsink is the SOC. The case is well-enclosed with minimal ventilation so I thought to get some temperature measurements going from idle into starting an FLI demo (which ostensibly would draw more resources from the emulation.) The chip never measured any hotter than the 114 degree reading in open air, but I suspect it does not get much hotter when assembled.
    Lowest and highest temperature readings
    One last point before closing out is a photo of what happened when I connected the C64 Mini to a monitor via an HDMI-to-DVI cable. What happened here?
    I have not been kind to this product which I expected to capitalize on the nostalgia set aflame by devices like the Atari Flashback and Nintendo's recently-released NES Classic Mini. And the hipsters who have no connection at all to a major centerpiece of my youth.
    I like to think I am a big boy and able to admit when I may have been mistaken, even through a large bite of crow. This may very well be that situation. I have made posts here at AtariAge and a couple of tech forums disparaging the mere inception of this device for various reasons, but primarily my disgust at how many vultures have picked through the rotting remains of a beloved machine.
    Having gotten my grubby hands on it and given it a good once-over I see its place. Given the right purposes, I see it making a handy option for toting around versus a full system. This is very much a nice combination of accurate-enough emulation and portability, and the ease of switching to support PAL-only games and demos is an immeasurable bonus. The native HDMI output, as with retro systems offering the same, is perfect for resolving the "240p problem" with modern displays.
    Given its physical appearance and attention to detail, accuracy of emulation, expansion capabilities, commitment to continued improvement of the firmware, the effort exerted to license games: I admit the THEC64 Mini is a pleasant surprise.
    Now, about that full-sized thingie.
    EDIT: As promised, I have included the programs and demos I used for testing, plus a few others I did not include in the videos.
  6. OLD CS1
    How about 800x600? HAHAHAHAHA
    No, but seriously. I will refrain from elaborating on my principle and philosophic aversion to New Year Resolutions (which nearly got me into trouble in third grade,) instead I want to make a short plan for 2018.
    First part of my plan is to finally buckle down on my conversion of Arkanoid for the TI-99/4A. I have put a ton of work into the assets so not finishing the game will be a disastrous waste and let-down.
    Secondly, I started on a project last year to produce a clone of the ForTI sound card which will connect to @jedimatt42's 32k clone. I have been working on specs for yet another sound player which will support such a card and including the mechanisms of instruments and patterns, which has also bred a simpler sound player for the same. This entails a couple of things: I need to learn a PCB layout program and write the two sound players to support the card. One player builds on the other so this constitutes a single part rather than two parts.
    Third, I have been working on assets for several other game conversions. In short: Demon Attack (based upon the 2600 version,) Gauntlet, and Ballblazer. I would like to actually execute the conversions but I am not confident I will have the time to do so. Ballblazer is something I have always wanted on the TI and the foundation exists thanks to @Asmusr; this will be an in-depth project for me but also fun as I have been studying the algorithmic process of creating the theme.
    While Gauntlet has been intimated and effectively claimed by another in the TI forum, this is also a game I have always wanted on the TI and would like to try my hand at. If it looks like I will not be on the road to started these games by 2019 I will release the assets I have built to that point -- sound, graphics, and whatever programming.
    Irrespective of the progression of the games themselves I will likely continue posting up my music in blog posts as I have been doing.
    Meanwhile I have been working on my sound_list.rexx script and expanding it to manipulate and perform conversions between ISR sound lists, PSG VGMs, and my special ForTI format. Once I adapt the script to manage stereo VGMs the simple four-chip ForTI clone format will be easier. The VGM output is working well and I am currently working on procedures for merging and optimizing lists and producing SIDdump-like outputs. In terms of creating, I have been looking at Deflemask, a multi-format tracker which includes PSG, as a replacement for my laborious use of Rasmus' SoundListRipper. Being that Rexx is a bit esoteric in the home computer arena outside of the Amiga world I have been tossing around the idea of converting to Perl, but that is way down on the priority list.
  7. OLD CS1
    The beige model of the TI-99/4A usually has the oft-maligned post action keyboard with a membrane contact system contained within which is prone to failure. In my first blog post I was both happy and disappointed to find a couple of variants of the beige keyboard which had, respectively, the spring-leaf style contact with full square action and a non-Mitsumi model with the hated membrane contact system.
    Generally the black keyboards are the full square action with spring-lead contacts. I am aware the black keyboards also came as post action models, but to my recollection I had not come across them before. Digging through storage this past weekend I found one black keyboard remaining from a bunch I was given some time back.
    Made by "General Instruments | Keyboard Division" (upper-left, poorly exposed)
      Keyboard post
    On the up-side, General Instruments did try to prevent this from happening.
    My original post on the good beige keyboard is below.
  8. OLD CS1
    I received the UltraSharp 2007FPb this week and tried it with both my Sega Nomad and TI-99/4A. There are some significant differences to the UltraSharp 2001FP which I covered before. Most importantly, as with the 2001FP the 2007FPb will sync properly to a 240p signal, though also samples it as a 480i signal.
    Dell moved the power supply into the monitor so it only requires the single simple IEC power cable. It has the same inputs and outputs as the 2001FP with some additional features, including PIP (picture-in-picture.)
    Functionally the monitors are the same, however I found the S-Video suffers worse quality than composite using the same composite source. I have a handful of composite-S-Video active adapters with a capacitor and resistor to prevent as much signal leakage between chroma and luma when separating, unlike many cheap adapters which simply wire the composite signal to both posts. These work demonstrably well with "good" video systems.
    But, sadly and interestingly a composite signal shows better on the 2007FPb than the actively split signal in the S-Video port -- the opposite of the results on the 2001FP. Check out these photos of the Micro Pinball II screen.
    I like the stand of the 2007FPb versus the 2001FP as it is flat and does not block as much usable desk space. I am still curious as the whether these two monitors will sync to a 15kHz signal from an Amiga but I will not be able to test as I lack the necessary Amiga video port adapter.
    Addendum: I discovered with
    † the 2007FPb does not smooth corners the way the 2001FP does. As a result, and what lead me to the discover, the ghosts in the game have more squarely-rounded heads on the 2007FPb whereas on the 2001FP the heads are pointy.
    † The way he was playing, I suspect he did not know you can also fill in holes and he could have achieved a higher score had he known.
  9. OLD CS1
    Having an affinity for and owning Sega Genesis and Genesis 2 consoles, I found myself intrigued by AtGames' new Sega Genesis Flashback. I have experience with AtGames' Sega Genesis Classic and Portable which I found lacking to some degree though usable, but the promises of an updated emulation engine and built-in HDMI were a draw which I could not resist. I have spent some time since the November 10 release to give it a whirl and I am far more satisfied than most early reviewers.
    Leading up to the official launch I watched videos and read articles by a number of reviewers who had been graced with review models. I cannot recall one overly positive review. I am not a professional reviewer and I am not a marketer so I shall jump right in to the meat.
    First, all of the AtGames Genesis devices are built on an emulator called "FireCore." From my own experiences and what others have posted around the webs I find FireCore has some limitations which seem unnecessary given how well other emulators play Genesis titles, including the free "MD.emu" which I run on my HP TouchPad†. I am left to wonder what the quality would be if Sega rolled its own emulation core the way Nintendo did for its NES and SNES Classic Edition products.
    The built-in HDMI makes the device a welcome addition now my entertainment system is digital at its core, though anyone familiar with using emulation on a high resolution screen should be able to relate to its one woe. I really do not mind the large pixels and blocky graphics resulting from scaling a "240p" screen to 720p. Many emulators have some kind of filter which provides output which roughly approximates the output on a TV, CRT, or other low-tech display. The Sega Genesis Flashback has only a scanline filter which puts faded lines between what would be the scan lines in an attempt to achieve the look of TV scanlines, and it really does not look good at all. Clean and crisp audio is also carried on the HDMI. While I lack the abilities to test, I suspect this configuration will not suffer the "240p problem." In fact, the only issue I have with the HDMI port is a problem playing nice with my ioGear Wireless HDMI kit, but a power-cycle of the ioGear transmitter resolves the issue.
    Speaking of power, while the Sega Genesis Flashback is rated to run on 5V DC at 2A, AtGames elected to use a barrel power connector instead of a micro-USB port like its recently-released Nintendo competition. I was able to power mine using a USB-A to 3mm/1mm barrel on an appropriate USB power supply, and the system under normal use pulls under 500mA. This made providing power to both the Flashback device and the ioGear HDMI transmitter much easier and makes the system more portable: both run just fine on my Anker PowerCore 26800.
    Getting back to the audio, playing some of the games I am certain I hear something different about the FM synthesized instruments, almost like the FireCore emulation uses different but similar instrument set (like a MIDI sound font.) To test this I whipped out my trusty Sega Nomad and ran games on both systems but I was not able to punch down any specific differences. So far on everything I tried the sound was near perfect.
    Video was another complaint on just about every pre-release review list. Glitchy graphics and sprites, and lagged screen scrolling being chief among the criticisms. Indeed, my prior experience with FireCore in the previous Sega Genesis Classic edition as well as the portable was not entirely perfect. Several of my cartridge games are not recognized by the Classic, and on both units my favorite game, Skitchin', suffered from missing graphics and sprites making it unplayable. I was very pleased to find Skitchin' works almost perfectly on the Flashback.
    I noticed on several games scrolling would suffer a short freeze which does not appear to be a frame-skipping problem as suspected in one of the early reviews. In fact, it appears the problem generally does not affect the entire screen but rather only a portion. For instance, in the original Sonic the Hedgehog one of the background planes stutters while animation on the rest of the screen continues. Realistically, I do not think most people will even notice, and if this is indeed a problem with the emulator or the horsepower of the machine I would further speculate AtGames counts on that presumption, as well.
    In this regard I noticed a couple of times when Skitchin' will completely freeze for a few jiffies, more of a short and quick stutter, but ultimately the game is still playable.
    Cool Spot is another great game which plays very well, though this is one of the games in which the FM music seems a little off-instrument but still perfectly acceptable. Shadow of the Beast will not play past the Electronic Arts logo, Flashback is not recognized at all while Out of this World plays beautifully, Frogger plays perfectly, and while the system comes with Mortal Kombat 3, my Mortal Kombat 3 Ultimate results in just a red screen.
    The last game I tried was Primal Rage, which suffered from strange graphics glitches which did not stop game play, such as a black line separating the vital stats area at the top of the screen from the battle area, and green borders around all screens except the title screen. This does not show on the Nomad, but I have not yet tried the game on a full Genesis console connected via standard video output so I cannot say for certain whether the green borders are normal. I would test with the Nomad but I seem to have misplaced the video output cable. Ah, well.
    I will repeat what prior reviews have said about the menu system. It is awkward, non-intuitive, and just weird. I have not found myself using the saved game nor rewind features, but I can see the value of both and imagine I will use them at some point in the future.
    Let us now focus for a few seconds on the hardware itself. The included controllers suck out of the box, with a capital "suck." The range is bad enough to prevent sitting across my living room and maintaining control, noting that my home environment is completely devoid of internally-generated 2.4GHz signals under normal circumstances: my phones are DECT, my wireless is 5GHz, Bluetooth devices are disabled unless in-use, and all 2.4GHz-only devices are turned off. Demonstrably, I have no locally-generated 2.4GHz signal interference. Initially it appeared they did not work even close-up, but the rebuild I describe shortly fixed this problem.
    The controllers just suck. When I originally un-boxed my Flashback I did not stop when I got to its rather touching rendition of the original console's gloss and textured black body and red "cylon eye" in front of the cartridge port. Inside I found three chips on a small circuit board, and what looks like one of those Arduino add-on modules, reminiscent of a "Bluetooth Shield" module. Soldered onto the antenna of this module is a red wire about six inches long, which is identical in both module and attached wire in each of the controllers. It looks like AtGames was aware of the poor range of the controllers and tried to engineer a quick-fix.
    As implied, I did take apart one of the controllers in the hopes of a rebuild improving its functionality. I found the standard complement of button, rubber nipples with contact pads, and exposed circuit pads one would find in regular controllers of the era. I grabbed my contact cleaning pen with harsh fiberglass bristles and gave the metal pads a few rubs each. Upon reassembling the controller I found to my relief it worked far more reliably and I could actually play games and even enter Mortal Kombat's "blood code." Thankfully the Flashback does support real Genesis controllers even if it only supports six-button units -- this remains untested for me, including the six-button arcade controller, as all my Genesis console hardware is stashed away for the moment.
    There is a USB port on the Flashback main board. It is a shame AtGames did not expose this out the back as a power port, though I suppose the reason is to prevent easy access to what I suspect is a hackable interface to the heart of the machine, probably in the near future -- not by me as I lack time for that kind of adventure.
    My assessment over-all is this is not a bad machine to have and use. If you do not have a Sega Genesis you should consider this as a possibility, weighing the benefits and caveats which are, as I see them:
    AtGames Sega Genesis Flashback Currently available for under $100 Built-in games (both Sega and classic Master System games) HDMI output (720p) Capable of using real cartridges Capable of using real six-button controllers Real Sega Genesis Not difficult to find Not too expensive depending upon source, most under $100 Some sellers will include a few common games Compatible with all Sega Genesis hardware Possible to expand with a Sega CD  
    AtGames Sega Genesis Flashback Alternate source pricing will double or more if and when stock runs out Included controllers SUCK Emulation is not quite 100% Not all cartridges work Does not recognize three-button controllers (not verified, and who really cares?) No guarantee homebrews or demos will work Real Sega Genesis Analog-only output requires up-scaling for digital home systems (on the up-side, the Genesis 2 has YPrPb component RGB output) No games built-in Upscaling will suffer the "240p problem" Old hardware is, well, old and subject to fail If you already have a Genesis, I believe the Flashback makes a viable surrogate for a digital entertainment system provided any lost compatibility is acceptable.
    † "MD.emu" is excellent on the TouchPad, including support for the iCade Core Bluetooth arcade joystick. It is available and actively developed for Android in both free and paid editions. I highly recommend this emulator.
  10. OLD CS1
    This monitor sports composite and S-Video inputs in addition to the standard DVI and SVGA. It works well with the TI-99/4A with some minor limitations. I took a little time to figure out how to get the best picture from the TI and give some information on what to expect.
    In 2006 I purchased two Dell UltraSharp 2001FP 20.1 inch monitors for the home office. Notably, these monitors not only have DVI and VGA inputs meaning I could switch between my Amiga 4000 and my Windows PC, but also composite and S-Video inputs meaning I could hook up my Commodore 128D, as well.
    These monitors still work just fine and sit on my desk with my Windows PC, Amiga 4000, and MorphOS MacMini, and I use the input selection to select the computer each screen will use. Works nicely.
    I managed to grab a third monitor for my play desk where my TI-99/4A, Commodore 128D, Amiga 1200, and Atari 130XE sit. Right now the only computer I have running due to space and time constraints is my TI and some fiddling was called for.
    The TI-99/4A console is a standard TI system (non-"QI") with no video output quality hacks. I started using it on the composite port to leave the S-Video port free for the Commodore 128D but I noticed the video quality was not at a level which made me happy. I grabbed one of my active composite to S-Video adapters to try. (These adapters include a capacitor and resistor to help separate the luma and chroma signals, unlike many cheap ones which simply run the composite signal through both input ports giving an image which is sub-par even for composite.)
    The difference is noticeable and much more usable than the composite input. I may use the composite input for something else, for instance an extension to connect temporary devices like the Jaxx Pacific many-in-one arcade sticks or the C64DTV.
    The differences really show with white graphics on a black background as these photos of Micro Pinball II demonstrate.
      Composite input
      S-Video input with active adapter
    Now, this monitor is not perfect and appears to suffer from the "240p problem" treating the input as if it were 480i. For certain, this means anything which flashes every frame will either always show or not show at all. In Micro Pinball II this made the game name graphic in the upper-left show as always white or always the original color, though the timing of either the monitor or the flashing is not perfect and every so often the appearance of the image will go the other way: always white then always colored, and vice-versa.
    Additionally, the S-Video input shows vertical lines which I believe to either the luma or chroma signal being higher-powered than the other. There is some difference in the aspect of the 9918A's video signal and the 1600x1200 monitor, so some columns are displayed wider than others, which is also another potential source of the vertical bands. Lastly, the monitor does some rounding of horizontal lines which softens the ends of letters like "E", and makes the ghosts in Midnite Mason appear to have more pointy heads.
    In this image the vertical lines do not show very well and rather the cyan screen shows more mesh-like†, but you can see the widened vertical lines and rounding of horizontal lines.
    The replacement for the 2001FP is the 2007FPb supposedly with the same input characteristics. I am not certain the difference over-all, but it turned out I was able to grab a 2007FPb cheaper and in better condition than another 2001FP when I last looked. It will not be here until next Monday but I got impatient and posted this in advance. If there is any significant difference I will post a follow-up.
    † A quick post-script on the "mesh-like" appearance: after a little reflection I recall the screen looking this way when displayed on a black-and-white TV through the video modulator. In any case it does not bother me at all and it does not detract from nor cause problems with using the monitor.
  11. OLD CS1
    I needed to swap around parts to build a beige TI-99/4A console using a standard main-board, "QI" power supply, and a keyboard which does not stick. The original standard board came in another beige console which at one point in its life lived in a smoking household, leaving the case stained yellow by, and with a sticky layer of, nicotine, and the keyboard suffering from the same ailments -- sadly as it is not one of the crappy post-and-membrane types usually found in the in the beige consoles.
    The donor case is from a malfunctioning "QI" console. Upon installing the standard board in the "QI" case I found the case would not close completely. I opened to inspect my work and found the board would not push into the GROM (cartridge) port trap-door assembly. After a minute or so of fiddling with the fit I discovered the problem.
    The "QI" GROM port assembly has two posts extruding from its bottom which block the metal covering of the standard board.
    The "QI" GROM port assembly on the left, standard on the right.

    I did not try the standard board without its metal shielding so I cannot say for certain the board will not fit without it.
    Something else noteworthy is the part numbers look very similar. Not knowing the way TI numbered its parts they look the same.
    The part number "1015982 N" is molded onto the assembly. The "QI" assembly has a "7" floating off to the left side while the assembly for a case holding a standard board has a "5." As well, the "QI" part has "-04XX" seemingly hot-branded above and to the right of the molded part number.
    Close-up of the part number on a "QI" GROM port assembly.

  12. OLD CS1
    Thanks to a Radio Shack solar project kit I owned in my youth, solar power and LEDs have always held my attention.  Solar accent lights are neat and handy for a number of reasons.  An entire industry of electronics parts exists just for these types of devices, not only simplifying the circuitry, but also lowering the prices to ridiculous levels -- motion-activated solar LED lights can be purchased for under $5!
    The yard variety of these lights tend to suffer from a hazing of the resin or other material used over the solar panels, eventually preventing them from getting a good charge off a day's sun.  In the past I tried various regular household cleaners, fungicides, mold and mildew treatments, buffers, and super-fine grit sandpaper to clean them, yet to no avail.  Many of these have wound up discarded because I could not get them restored.
    Early this spring I was staring at one and mulling over a number of variables when something clicked.  The bottom line: these look a lot like water spots on black car trim.  I could have tried some CLR or Lime-Away on the lights, but I was concerned these would be too harsh and cause damage.
    Thinking back to my car, a nonsense idea occurred to me: Mothers Back to Black.  Recommended to me by my body shop to put the sheen back into the unreasonable amount of black plastic trim on my car, I figured it could not hurt to try.  Such a simple solution, and it works a treat.  Of course, like anything else which gets cleaned or restored, this is not a fix which lasts forever.  I found that I have to re-apply after a month or two, depending upon rain and yard watering.  (Oh, and bird poop.)  I also have added a little bit of a tilt to them to help water run off, though you may be able to tell the coating over the panels in my lights shown are recessed and tend to create a small pool.

    Mind you, this does not account for the yellowing of lower-quality resin or plastic covering a solar panel.  That is a whole other problem with which to deal (or just chuck and replace.)  I had about twenty at one time I picked up from Ace Hardware.  The cover on those was domed and helped prevent water build-up, but it also yellowed and darkened to the point of being unable to produce a good charge voltage or current.  The ones I show here are from WalMart and are about seven years-old.
    Another tip for longevity is to replace the batteries which come with the lights.  Every one I get has a cheap cell holding about 200mAh to 450mAh, which is not only not enough to keep them lit for long periods of darkness, but also less than what the panels will pump into them in a fairly well-lit yard over the course of a day.  This will result in overcharging the battery, eventually causing battery damage and leakage.
    You can pick up larger capacity NiMH cells from the WalMart garden center or many local outlets.  I get the 1500mAh "AA" and they can keep a simple 5252F-based circuit with a color-changing LED running for almost eight hours.  As well, the cells are 1.2V, and the panels shown here output right at 1.2V under moderate to full sunlight.  Many smaller lights have smaller cells: some AAA, but I have picked up a few recently which have 2/3AA and smaller.  Thus, replacing the battery may prove to be more difficult.  I have not tried commercial brand rechargeable batteries like Energizer or Duracell.  While I suspect they will work just as well, these lights get very hot under direct sunlight so that may effect longevity of the battery.  As always, your mileage may vary (YMMV.)
  13. OLD CS1
    It is shockingly easy to move an iSCSI LUN from one Netgear ReadyNAS OS 6 device to another.  This exercise is performed on version 6.7.2, the latest version at the time of writing.
    Netgear's official method for migration is to create new new iSCSI LUN on the destination device and mount it in your operating system -- I am doing this in Windows.  Then use robocopy or your favorite mass copier to copy the data from the old LUN to the new LUN.  This could take a long time if you have a lot of data, especially if your data consists of a lot of small files (photos, phone videos, etc.)  My data is a healthy mix of small (photos, music, and such) and large files (ISOs, VDI/VHDs, etc.) as well as a lot of files encrypted with EFS.
    This is gonna take for-e-ver.
    Logging into my NAS through SSH and poking around I found there is an iSCSI backing store file for the LUN.  It is conveniently located in /data/(name of your LUN)/.iscsi/ with the name iscsi_lun_backing_store.  Simple!
    I was originally copying the non-iSCSI files from the old to new NAS using rsync, but the rsync configuration does not allow you to select the root of your data store (/data) but instead you have to select each and every share.  When I tried using SMB, I found I could select /data and about 13 hours later I had an exact copy of my old NAS data on the new NAS.
    INCLUDING the iscsi_lun_backing_store file and the associated .serial_number file.
    So, the process became to create the new iSCSI LUN on the new NAS with the same name, size, and block size configuration as on the old, then run the backup task on the old.  I let that rip and sure enough the backing store file had copied.  Then I connected to the new LUN, took a quick dash into diskpart to bring the drive online and holy-o-crap!  I had two identical drives mounted on my Windows desktop, the second having an intact NTFS file system and randomly-select files all check out.
    The next step is to see if the app data for Plex will be usable in the same way as all of its directories copied over, as well.  I installed Plex and disabled it before the backup migration.  The hope being that upon starting up, all of its databases and configurations will be right where expected, and I will now have a complete Plex mirror of the old NAS.  This would be the second and last step in data migration which would make my life (and this process) much easier.
    UPDATE: Moving Plex to the new NAS was a little more work as the actual Plex application files (database, bundles, etc.) are stored in /apps.  I copied the entire plexmedia directory (~110GB) to the new NAS via an external hard drive.  Once I started the Plex app on the new NAS it loaded everything as expected.  I had to make minor settings tweaks, such as the local interface, but otherwise all seems to be working fine, including the device logging into Plex.tv servers.  One important thing I forgot was I had upgraded the Plex server on the old NAS.  While the new NAS indicated the correct version within Plex, the system detected otherwise.  Installing the upgrade version went without a hitch.
    Nothing short of a Christmas miracle!
  14. OLD CS1
    What is the value of a $40 power supply? To the guy who built it, that may be $20 in parts and some labor, plus the time to research the necessary parts and the recognition of the need for the product in the first place.  What about when he ships out the wrong power supply and then exchanges it, but through an eBay quirk the buyer winds up not paying for anything?
    One of the first computers I touched with a GUI was my grandfather's Atari 520ST some 30 or-so years ago.  After his retirement from the Air Force he worked in a few jobs, one as an electrical engineer designing and building motors.  He used a CADD program on his ST to do work at home.  "Boomers" get a bad rap today for being technologically inept and largely incapable of using computers, but not only did his generation largely invent the damned things but he and many of his cohorts did and do quite well.
    He spent time with me setting up some floppies to use for drawing, my own CADD stuff, some games, even programming in GFA BASIC.  While I still have those floppies, no one seems to know what happened to his collection after he passed.
    Recently I picked up an Atari 520ST just like his and in near-perfect condition, though it lacks a floppy drive, power supply, and monitor.  I have set out to build this system and came across a custom Atari ST power supply on eBay.  But the seller shipped me an Amiga power supply!  A very nice one, but I already have plenty of those.  He immediately offered to exchange it.  I just had to process a return and he immediately shipped me a replacement.  I received a refund and several days later I received the replacement.
    After a few exchanges and looking through PayPal and eBay I found I did not have a way to pay him.  Not only that, but having me pay for the item outside of an eBay auction would put him in peril of violating eBay policies.  Sure, there are some ways he could have handled this to square it up and get his money, but instead he offered to let me keep it.
    While trying to "rebuild" my grandfathers computer -- the one which launched me into graphical environments owned by a man who had a long-lasting influence on me -- though my time-line took me through Amiga rather than Atari, I found a $40 custom Atari ST power supply and the generosity of a stranger to be invaluable.
  15. OLD CS1
    SonyEricsson's PC Suite had a nice feature which would synchronize your phone's clock to your PC's clock when establishing a connection. I found more often than not my frequently-synchronized computer time differed by a minute or more from the Cingular/AT&T network time.

    (quick bitching about Sony)

    Since PC Companion no longer synchronizes my phone's clock with my PC, using the SonyEricsson AT Commands reference guide I wrote a Powershell script to take up the slack. The script opens the Bluetooth COM port set in the first line (no error checking, sorry so lazy) which is COM14 on my laptop, then sends the AT*EDST and AT+CCLK commands to set daylight saving time status and the clock, respectively. Setting DST is extremely important for setting appointments as I do not enjoy being an hour late or early.

    Since Get-Date returns the local time adjusted for DST, the time submitted to the phone must compensate. The IsDaylightSavingTime() return from the Get-Date object is perfect for this as it returns 0 for "not DST" and 1 for "DST," so this is subtracted from the current hour. The important here trick is to clear DST before setting the time. Otherwise, the phone accepts the given time as the current time including DST, but since DST has already been accounted for the time gets set an hour off.

    *EDST is sent to the phone first, per SE recommendations, then +CCLK. $seTZ holds the time zone offset, which is the offset from UTC in quarter-hours, calculated by comparing the local time to UTC, adjusting for local DST, then multiplying by 4. Finally, the real DST setting is sent.

    I put one-second pauses between sending each of the three commands to the phone. Without this pause commands will sometimes get missed. I suspect this is due to not reading the phone's responses which I do not try to read. This is a very primitive script which does not check to make sure the port is even open, so why even bother registering an event for reading the port?

    $sePort = new-Object System.IO.Ports.SerialPort COM14,9600,None,8,one$sePort.Open()$sePort.WriteLine("at*edst=0`r")Start-Sleep -Seconds 1$seTime = Get-Date$seEDST = If ($seTime.IsDaylightSavingTime()) { 1 } else { 0 }$seTZ = (($seTime-$seTime.ToUniversalTime()).Hours-$seEDST) * 4$seCommand = "at+cclk=`"$($seTime.AddHours(-$seEDST).ToString("yy/MM/dd,HH:mm:ss"))$($seTZ)`""$sePort.WriteLine($seCommand+"`r")Write-Host Time command $seCommand sent to SonyEricsson phone.Start-Sleep -Seconds 1Write-Host Setting DST on SonyEricsson phone to `"$seEDST`"$sePort.WriteLine("at*edst=$($seEDST)`r")Start-Sleep -Seconds 1$sePort.Close()Write-Host ** DONE **
  16. OLD CS1
    I can be an asshole and sometimes a bit crotchety. It was a relief, therefore, to find that I am not the only one who finds the concept of "life hacks" cringe-worthy and often aggravating, if only for misusing the word "hack." You might come across some viral new "life hack" and think, "nothing special about that," since you or someone or some group of people you know have done this particularly amazing thing forever.
    The latest one which grabbed me the wrong way was the whole "eating your hamburger upside-down" thing, since my dad taught me that for when working with sloppy burgers (like Sloppy Joes.)
    What the heck, I thought. Maybe I should just post up one of my stupid things. Maybe it will go viral and I can earn another 30 seconds of my promised 15 minutes of fame.
    Bachelor living life hack!
    Most bachelors, and some beyond, will keep dishes in the kitchen sink for several days at a time. Rinsing dishes and even giving them a quick soapy splash will help knock off food and keep it all from getting too stinky. Even so, dishes left in the sink tend to collect dirty water and foster organic films of nastiness. Bowls especially like to collect fouled water which becomes smelly. I have even seen it turn a greenish color (still have not figured that one out.)
    A simple solution to keeping bowls in the sink for a few days before washing is to rinse them well then set them in the sink upside-down. This allows water to drain completely and prevents the bowl from trapping more ick.
    Of course, an arguably easier solution is to not allow dishes to collect in the sink. Often easier said than done.
  17. OLD CS1
    I have held season tickets since earning my Criminology degree at Florida State University (FSU.) Before then I attended games as a student, and even before I was a student I attended games with friends who were students.
    One thing to which we held firm was we always showed up on time for kick-off and we never left early. Of course, in the early days there was little reason to leave early unless, for pity's sake, you simply could not stomach watching our boys on the field win the game by enormous margins. Florida State was in the midst of a great dynasty under head coach Bobby Bowden, and irrespective of your feelings toward Bobby or the team, we as a school played like winners both in the stands and especially on the field.
    The energy was unstoppable.
    Things have changed over the years with the eye-opening moment standing in the student section at the north end zone when we lost to North Carolina State, experiencing our first ever Atlantic Coast Conference loss at home. A painful loss in which our oft-maligned quarterback Chris Rix marched the team down-field in the last two minutes of the game, from our 22 to N.C. State's 15, and threw a touch-down pass in the last remaining seven seconds.
    At least, from our vantage we thought it was a touch-down pass. In reality, P.J. Ward (#24) barely missed the reception due the ball slipping through the hands of N.C. State defender Lamont Reed (#28,) knocking the ball down. With three seconds remaining, under pressure at the 25 yard line, Rix put up one of his beautiful and strong passes to the back-left corner of the end zone to a double-covered Talman Gardner (#21,) who went up for the ball but, as was often Rix's way, the ball was just inches too high.
    N.C. State won the game 34-28. Those last two plays so critical and could have meant we eeked out a one-point win against a tough team in a tough game. This, however, was neither the source of my disgust nor what turned me cynical toward my fellow fans.
    No, it was how the student section and many of the alumni near us turned their backs on the team as they came off the field to the tunnel below us. Livid. Irate. Furious. These words lack the bite of what I felt that day toward those in the stands with me.
    Over the years I have watched a decline in the team and the fans. Fans screeched, howled, and demanded Bobby's head over his reluctance to eliminate his son, Jeff, from a coaching position he obviously could not handle. Before Bobby's retirement we learned he would be replaced by Jimbo Fisher, who the following year rode shotgun to the strength of a young and impetuous quarterback Jameis Winston. As incorrigible as he was, Jameis is also a born leader who lifted the team and held spirits high, eventually winning Florida State the last ever B.C.S. National Championship.
    The team became disjointed on the field and made ever-increasingly ridiculous blunders. Without Jameis, Fisher's flaws and lack of dedication to the program began to show. Then, with the glaringly obvious trajectory of the team, previous set-backs in his personal life, and the lure of money he wanted and facilities he desperately coveted, Fisher left Florida State for Texas A & M.
    Fisher has since been replaced by Coach Willie Taggart, who came here excited to be a Seminole -- excitement which brought a breath of fresh air to the sport versus Fisher's very closed and blunt business-like presentation -- with a bright outlook and fresh attitude toward the team. Many people expected to be a winning team out of the gate, but I found a more measured outlook understanding this was the first year under a new coach, a rebuilding year so they say. A lot of work needed to be done to bring the team back from the mediocrity which had gripped it under Fisher, and a lot of old bad habits had to be shaken. Habits back into which you can see players falling when under pressure. As with all things, in a crisis you fall back on your training, and these boys had not been well prepared.
    Now for the embarrassment that was the 2018 match against Clemson and its frustrating factors.
    I spent all day Sunday stewing over the game and the performance of our players which led me to leave a game early for the first time in 20 years. I buried myself in household chores and electronic hobbies, deliberately trying to avoid anything related to the game to prevent both my thoughts being clouded and me from boiling over in both anger and disappointment.
    Chances are those who do not "get" the emotional attachment some people have to sports are likely not to get this, either. Fans are an important part of the game and a heartbeat for the team. When the fans have energy so does the team. When the team performs well that energy increases. It is a self-feeding symbiotic relationship. I am not a professional football fan for the reason that I am a college football fan now and was a high school football fan before.
    Playing sports as youths we learn to play hard, to give the game more than what we have, and that "losers" only ever "do their best." Play hard and you win big and sometimes you lose big. In both cases, however, you should learn something. As a former manager used to tell me, "the biggest room in the world is the room for improvement."
    Our parents told us there is little worse than wasted talent and potential. Your parents, peers, mentors, teachers, coaches, even managers cultivate it. Even with all the positive influences, you have to be willing to be guided and molded, and you have to execute. Some more than others, we all have it within us to overcome adversity and life's obstacles. I enjoy watching these kids grow and advance and transition from wet behind the ears to strong and confident both individually and as a team. I take pride in our mutual love for our school and our desire to be better than the best we can be, knowing that our school provides a supportive and nurturing environment for bettering one's self, and prepares us to continue to grow and mature well past our college years.
    The past few seasons of Florida State Football have been a stark contrast to our teams of old. We would many times spend the first quarter or so feeling out our opponents, making a few mistakes as we adjusted to their strengths but also exploiting our strengths to put up points. Sometimes we would be behind later in the game but would pull it out in the end, as "fourth-quarter team."
    Now, however, in the face of a strong adversary, offense shuts down toward the end of the third quarter and defense follows mid-fourth. All of this follows little if any exercise of team strengths to put points on the scoreboard.
    Even with a new coach, with a fresh attitude, with renewed fan excitement, support, and vigor, we were presented with the mess this last Saturday. For that performance these kids should all be ashamed. If they are not then Coach Taggart needs to make them feel ashamed of themselves. It was clear to everyone watching that these boys flat out gave up, and even the ones who were genuinely trying were up against not only Clemson but their own teammates who had already quit playing.
    Shortly after the muffed punt return in the third this fact was all too clear to me. I pointed out that they had given up and there was no reason for us to stay. Never in 20 years of attending Florida State football games had I left early. I was disgusted with the team for its waste, myself for feeling this way, and the team again for making me feel this way.
    The team's failure does not rest solely on the players' shoulders. In fact, during the game we witnessed numerous times when plays were taking damn near forever to get called in, leaving already stymied players even more confused and constrained for time. Indeed, the coaches need to step up their game, as well.
    To address and not forget, the punches thrown by Noonie, White, and Murray should earn all three bench seats for the rest of the season. There is no room in our game for, and unsportsmanlike-like conduct does not adequately describe, this loser behavior. Period. We certainly do not need to descend into the same thuggish behavior and mind-set we have decried for many years coming from other teams.
    All around, it is time for the coaches to be coaches and not players' buddies, time for players to get their heads out of their behinds, and for everyone, including the players themselves, to demand from the entire team all of what it is capable.
    I have been complaining for several seasons about the shushing of the crowd while we are on offense, as back-in-the-day we cheered whether we were on defense or offense. The team trained to play in constant noise, loud noise, in particular because some of our competitors are homed in incredibly loud stadiums. Deafening stadiums, even, like The Swamp at the University of Florida. Shutting down the fans' energy during offensive plays, only allowing small outbursts on good plays, is a momentum-killer for the fans. It is difficult to maintain when you have to keep stopping. While I have complained about this, I had it pointed out to me this shushing really gives you an idea of the team's head-space.
    Maybe this will not be the year we pull it together to regain our winning acumen, but in the process we should not accept this downward spiral. I will continue to show up and support our boys but only if they give themselves and us 100% or better. While I love my school and I love my team, love is a two-way street and we fans are not getting back what we put in. Indeed, it is time for Coach Taggart and his staff to "Do Something."
  18. OLD CS1
    I do not have the time available yet to jump back into the forums as I have been cleaning up my home-office and integrating my former state office. Part of the process involves archiving items in storage for long-term safe-keeping.
    While I am not certain how available these are, I figured mine are in good enough condition to go ahead and scan up.
    Included are 300dpi PDF and black-and-white TIFF† scans of both the beginner pack included in an envelope in the box, and the loose quick reference sheet.
    Sometime later I will do more detailed scans at 600dpi and correct some of the defects introduced by the scanning process.
    † TIFF files are in the Zip, as TIFFs are not allowed uploads on AA.
  19. OLD CS1
    After hearing a couple of remixes of "Bruce Lee" from the Commodore 64, I was compelled (distracted?) to make a quick conversion and my own little remix (not yet completed,) both in TI-99 ISR format. This particular piece is a good candidate for its own special player, being that the format of the song is roughly A-B-B-C-D-D-C-(E-F-G)-H. Nothing fancy in terms of a player, just one that can do repeats and patterns.
    Original Commodore 64 SID:
    I have provided my conversion as an MP3, and as usual a binary which can be loaded via Rasmus' SoundListRipper.
  20. OLD CS1
    I needed a short example to try out some of my Rexx script transforms. The main thing this demonstrates is taking a bass-line in tone channel three and changing it into a periodic noise bass-line. The transform command is "nb" so the files are named accordingly.
    The script is still a work-in-progress missing some functions and sloppy as hell so I will not be showing it off just yet. Plus there is a major bug in the remove transform which removes a tone from a list, which instead winds up corrupting the list to the point that it cannot be recognized. I am also working to implement giving transforms line ranges. But enough of that. Enjoy these.
    Xevious - Start Game (TMS-9919).mp3
    Xevious - Start Game(faster).bin
    Xevious - Start Game (NB) (TMS-9919).mp3
    Xevious - Start Game (NB)(faster).bin
    Xevious - In Game (TMS-9919).mp3
    Xevious - In Game.bin
    (updated to include start-game source sound, captured using Audacity via Windows StereoMix)
  21. OLD CS1
    Vorticon asked me to provide the sound effects for his TI conversion of
    . I started working on them and at the same time picked back up on Rasmus' challenge to me to arrange "Monty on the Run." I have been bouncing between Jetpac and Monty, as well as my A/Rexx script to manipulate ISR sound list binaries. Tonight I was playing with the Monty bass-line, over-laying it with a SIDPlay export (Monty_on_the_Run.mp3) and I thought I would share part of my process for doing my conversions. It is nothing special but I enjoy it. 
    I am using SIDdump to dump the original SID to a text file using time sequence instead of frame numbering. I take those tones and bump them down an octave or two to match up with the 9919's idea of octave numbering and finagle the timing. 1/60s does not always match a SID frame so sometimes it is not possible to get exact timing, but close enough. (A quick related note on Jetpac sounds: the time resolution in the original ZX game is about double that of the TI ISR, so the sound effects are four, sometimes five, distinct tones in the space of two or three on the TI so I have to finagle that, too.)
    I am using Rasmus' excellent Sound List Ripper, which he has admonished me (nicely) for using in this capacity. It is not a tracker but it works for my purposes. With this and my A/Rexx tool, which is still very much a work-in-progress, I can do quite a lot very quickly.
    In the video below (low quality on my old phone, but the sound is good,) you see (not clearly, heheheh) the SoundListRipper window open on the left, the VLC window playing the Monty on the Run music, and the Windows audio mixer at the bottom I am using to give the SLR more volume over VLC. At about 0:41 and 0:47 I mute VLC so you can hear the output of SLR, which is a very accurate simulation of the 9919's output. (Yes, I know I can control the volume and mute in VLC.) You will also hear where I mis-fired the SLR to start it too early.

  22. OLD CS1
    Actually, I am not really certain what to call what I am doing here. Essentially, I need a table of values which can be referenced both by number (ordinal) and the value itself (associative.)
    I reach back to the TI-99 ISR (interrupt service routine) sound lists for a practical example. I want to create a transform which will increase or decrease tone values by semitones or octaves (12 semitones.) To do that, I have to load the channel sound command, which consists of two bytes, from the list. Some manipulation has to be done to convert it from (for example) >8C1F to >01FC, A-1 on channel 1, but that is another exercise.
    Now I have my tone value. Say I want to increase this by an octave to A-2, >00FE. While I know an octave is 12 steps, I have no way of knowing that >00FE is 12 steps away from >01FC unless I have it in an indexed table in which I can count the 12 steps to find the value. But I also need to know at what index the initial value resides. I have not used a language with associative arrays which can actually produce an index as the elements are usually stored as some kind of hash. You can step through all of the elements, but not in any useful order.
    To accomplish this I only need one variable but two ways of storing information. The first will convert a given value to an index, and the second which can then convert an index to a value.
    In the example below I am doing this, as well as something else I consider neat. I am actually storing the list of values I need indexed in the script I am running as a long comment. Sure I could have dome some kind of Fu to get a long monotonous list of assignments (in this case 150,) but this method allows me an easy (and did I mention neat?) way to build the stem variable at run-time and more simply maintenance the table.
    The script scans through itself looking for its table values. In this case I am indicating a wanted value with the ">", which is the hexadecimal notation prefix in 9900 assembler. As the routine takes in values it increments the index variable. Each value is stored in two ways using the same stem: the index is stored as an associative leaf, then the value is stored with the index as its leaf. TONE.0 is used to store the length of the table for walking.
    Thus, the script is

    TONE.value = index
    TONE.index = value  
    If value is 01FC and index is 13, A/Rexx executes this:

    TONE.01FC = 13
    TONE.13 = 01FC  
    Remember, I want to increase this tone by an octave which is 12 semitones. Because I know the value I can now find the index. The new index is 25, and TONE.25 gives 00FE. Done!
    I can use this one stem variable to work in both up and down directions, as well as between index and value, for whatever purpose.
    In the script below, the table is read from the comments at the end of the file. To save time in longer scripts I also facilitate a termination value to stop reading the file any further once the end of the table is read. For some reason i was unable to get BREAK within the DO loop to work in Regina Rexx and I did not try it in ARexx, though the script does otherwise work in ARexx if you comment out or remove the OPTIONS line. As well, since the script was created in Windows it contains carriage-returns at the end of lines, so I had to PARSE that out. If the build routine is fed a file which lacks carriage-returns, the last character of the pattern simply does not get matched and it still executes as expected.
    Once the table is read into the stem variable, it is then walked and output to the screen, thus proving its might.
    This routine could be adapted to handle more than a single table in a file. For that matter each table could be stored in separate files, but storing the table or tables in the executing script just makes less clutter in the file system. Plus it is kind-of neat.
    For my purpose, and ease of constructing the two sound channel command bytes, I can and most likely will change the order of the nibbles in the table. Done this way, building the sound channel command is a simple BITOR() instead of a more involved process of swapping nibbles around in the script.
  23. OLD CS1
    I have been working on some Rexx scripts to manipulate sound list binary files exported from Rasmus' soundlistripper. I ran into a few problems here and there, and found these problems were mostly due to my experience in ARexx, Amiga REXX, which has some differences compared to various Rexx interpreters. To demonstrate my lacking in "standard" Rexx I went back to basics and wrote a simple dump program.
    This is also where the statement OPTIONS AREXX_BIFS AREXX_SEMANTICS comes into play.
    This requires the latest Regina Rexx (3.9.1 at the time of this writing.) In particular because earlier versions (not sure where the cut-off is, but for certain 3.7) seem to only allow a stream of around 1.5k bytes. The Regina manual states the limit on a single line with READLN() in ARexx is 1,000 characters, while the rest can be read via READCH() or additional READLN(), but I found some sources which indicate a maximum of 64k bytes. In any case, there was definitely a limitation on Win64 reading some long sound lists via READCH() which was resolved by upgrading from Regina 3.7 to 3.9.1.
    I had to make some other adjustments to get my ARexx-fu to work in Regina, but at least now it does work and I can go back to the larger manipulation program and fix my stuff. (For one thing, I need to make the program more modular and have just a single section for input and output rather than in each manipulation.✝)
    If you have .rexx associated with Regina and Regina is in your PATH, you can execute the script below like this:
    sound_list_dump.rexx filename
    The input file is a raw binary dump of an ISR sound list, the output is 9900 assembler BYTE statements representing the contents of binary, one statement per row. This does no checking on the content of the file other than watching for a duration of "0" which indicates the end of a sound list. So unpredictable results occur if you feed it something else.
    ✝ The last update I made to this post includes changes to use a stem or compound variable, which is essentially an array, to store the loaded sound list. This make manipulations far easier. For instance, swapping or copying channels, changing tone frequencies, changing channel attenuation, etc. As well, I made changes to the way I was calling WRITELN() and WRITECH(). I had not used these in ARexx so I was not following a proper convention, calling them as functions. Using CALL corrects this.
  • Create New...