Memory Probe program

[+Lathe26]

While there have probably been a dozen such programs already written, I figured I'd contribute it here. So anyways...

 

Introducing Memory Probe!

This program, written in IntyBASIC and some assembly, enables new developers to explore and manipulate the Intellivision's memory as well as the memory of pass-through hardware such as the ECS and Intellivoice. Specifically, users can:

1. View memory locations in the following formats:
   1. Binary
   2. Decimal
   3. Hex
   4. Pixels
   5. ASCII
   6. GROM card index
   7. GRAM card index
   8. Backtab value
2. See which bits are read/writable vs which ones are hardcoded as 0s and 1s
3. Use Mattel-style bank-switching
4. Change the value at an address (in hex or decimal)

In the animated GIF above, some of these features are demonstrated such as:

• Adjusting the video offset
• Resetting the video and audio (handy for users who accidentally entered annoying values)
• Display a volatile memory location
• Scrolling through the pixels in GROM memory (watch the pixels)
• Scrolling through the code in GROM memory (watch the ASCII)
• Showing ECS BASIC strings
• Bank-swapping an ECS ROM out and back in again
• Switching to Foreground/Background mode and back to Color Stack mode
• Change memory bit probing from read/write mode, to read-only mode, to off
• Switching to Color Stack mode
• Displaying the pixels for the ECS musical notes

Instructions

Memory Probe is intended to be discoverable by new users. As buttons are pressed, it gives a brief description of what they do.

 

Even so, the details of how to operate it are here.

 

Modes

In normal mode, use the disc up/down and left/right to scroll through the memory address range. Different speeds are possible when the side buttons are used with the disc. In order from slowest scrolling to fastest scrolling, they are:

1. Up/Down with a Top button
2. Up/Down
3. Up/Down with a Bottom button
4. Left/Right with a Top button
5. Left/Right
6. Left/Right with a Bottom button

To change into a different mode, use the keypad to change modes:
1 - change address via typing
2 - change value hex
3 - change value decimal
4 - Enable/Disable Cards (overwrites GRAM)
5 - Toggle FG/GB vs Color Stack video modes
6 - Change bank (ECS / Mattel bank swapping)
9 - Toggle between read/write probing, read-only probing, and no probing
Clear - Silence audio and reset video

 

Typing in a decimal number is done normally with the keypad.
Typing in a hexadecimal number is similar to T9 typing on old flip cellphones:

• Press 0-9 once to select that digit, press 1-6 twice to select A-F as the digit.
• Press Enter to move the cursor forward or wait a moment for the cursor to auto-advance.
• Press Clear to move the cursor backwards.

In either typing mode, the disc can still be used scroll through values instead.

Screen layout

• Top left:
  • Addr The 4-digit blue number is the current address.
• Table on right side of the screen:
  • Header The 8-digit blue number is the column header; each digit here is the bottom digit of the address and the 7 addresses that follow it.
  • AscH/AscL The high byte or low byte of the value at the memory address (and the 7 that follow it), displayed as an ASCII character. If it is ">Asc", then the character set being used is a superset of ASCII. "<ASC" is when a subset of ASCII is used (no lower-case). Note: technically, the Intellivision's "ASCII" is close to displaying true ASCII's 95 displayable characters, but instead displays 2 arrow images instead of the proper ^ and _ characters.
  • GromH/GromL The high byte or low byte of the value at the memory address (and the 7 that follow it), displayed as an index into the GROM table.
  • Bktab The value at the memory address when placed into the Backtab (and the 7 that follow it). Thus value encodes what GROM/GRAM image to display, what its color is, etc.
  • GramH/GramL The high byte or low byte of the value at the memory address (and the 7 that follow it), displayed as an index into the GRAM table.
• Table on left side of the screen:
  • Pixels Displays the data at the memory address (and the data that follows it), as pixels. The H column is the high byte data, the L column is the low byte data, and W is the entire word of data (low byte displayed on the line above the low byte via line-wrap). This display feature is normally turned off since it overwrites GRAM memory but is easily turned on via the keypad.
• Bottom of the screen:
  • This area displays more info about just the data at the current memory location.
  • 54321098763210 Column header to indicate the bit position of the values underneath it. Starting at the right, bit position 0 is indicated with a 0, bit 1 with a 1, and so on left-ward until 9. The 0 through 5 in middle-left of the screen indicate bit positions 10 through 15.
  • R/W? Displays each of the 16 bits after probing it. It displays whether each bit_index is hardcoded as a 0, as a 1, or whether it is read/writable. Use the keypad to disable this feature when their address is sensitive to reads or writes (ex: ECS UART addresses 00E0-00E3 or PSG envelope registers at 01FA and 00FA).
  • Bits The value stored at the address displayed as bits.
  • Hex The value stored at the address displayed in hexadecimal.
  • Dec The value stored at the address displayed in decimal.

Known issues

1. Modifying some STIC registers doesn't work because IntyBASIC automatically overwrites the values.
2. When the ROM is loaded into the LTO FLASH application, the ROM is displayed with a "warning" icon (black exclamation point in a yellow triangle) with the message "ROM file is present, but has been modified". This warning can be ignored. It is the result of a work-around of a bug in the IntyBASIC compiler's --cc3 option.

Tested against

• Intellivision (original Mattel)
• "Tutor Pro" system
• ECS
• Intellivoice
• jzintv on Windows and Android (note: Android's jzintv4droid does not load ECS or Intellivoice ROMs with Memory Probe)
• Keyboard Component

MemoryProbe.zip

MemoryProbe Source Code.zip

[+Lathe26]

Of course, feedback is appreciated.

[+Lathe26]

Lastly, if anyone knows how to make the "warning" icon go away with the LTO FLASH app let me know. My understanding is that this is because the build script works around the --cc3 bug by editing MemoryProbe.cfg to add the RAM to the memory map and then runs bin2rom to rebuild the rom file, all of which means the code's checksum that IntyBASIC generates early in the build process no longer matches the modified final binaries.

[+cmart604]

Box pics?

[+DZ-Jay]

GotY?

[+eebuckeye]

Snow level?

 

That does look really cool and I would think could help programmers.

Edited November 15, 2018 by eebuckeye

[carlsson]

Snow level is when you change the wrong location that causes the power to shut off and you end up with static.

[+Lathe26]

Snow level?

...

 

Snow level is when you change the wrong location that causes the power to shut off and you end up with static.

 

Perhaps I'll add a snow level... or perhaps I already have...

 

https://www.youtube.com/watch?v=a1Y73sPHKxw

[intvnut]

Lastly, if anyone knows how to make the "warning" icon go away with the LTO FLASH app let me know. My understanding is that this is because the build script works around the --cc3 bug by editing MemoryProbe.cfg to add the RAM to the memory map and then runs bin2rom to rebuild the rom file, all of which means the code's checksum that IntyBASIC generates early in the build process no longer matches the modified final binaries.

 

Perhaps you could sync with Steve Orth and I over email to figure this out, to see if there's a real problem here.

 

Mainly, this icon shows up when the GUI sees that the ROM on disk mismatches the ROM in LTO Flash. If you're just adding already-built ROMs to your menu, that icon will only show up until you sync with your LTO Flash. If you're actively modifying and rebuilding the code, then the "needs updating" icon is largely Working As Intended.

 

Now, if you're just recompiling without changes, and the ROM goes through a couple different checksums and triggers the "need update" icon even when the final binary ends up unchanged, then perhaps that's just us being conservative.

 

I haven't looked at your build-script and what it does to the CFG. If you need a particular region of memory marked as RAM, perhaps adding an "ASM MEMATTR" line to the BASIC source could get it marked appropriately up front. That could remove that additional twiddle. Feel free to sync with me here or over email to figure out how to simplify that step.

 

I prefer email mainly because it's easier for me to focus my attention on my inbox. I don't spend a lot of time on AtariAge these days.

[+Lathe26]

Perhaps you could sync with Steve Orth and I over email to figure this out, to see if there's a real problem here.

 

Mainly, this icon shows up when the GUI sees that the ROM on disk mismatches the ROM in LTO Flash. If you're just adding already-built ROMs to your menu, that icon will only show up until you sync with your LTO Flash. If you're actively modifying and rebuilding the code, then the "needs updating" icon is largely Working As Intended.

 

Now, if you're just recompiling without changes, and the ROM goes through a couple different checksums and triggers the "need update" icon even when the final binary ends up unchanged, then perhaps that's just us being conservative.

 

I haven't looked at your build-script and what it does to the CFG. If you need a particular region of memory marked as RAM, perhaps adding an "ASM MEMATTR" line to the BASIC source could get it marked appropriately up front. That could remove that additional twiddle. Feel free to sync with me here or over email to figure out how to simplify that step.

 

I prefer email mainly because it's easier for me to focus my attention on my inbox. I don't spend a lot of time on AtariAge these days.

No prob, I'll ping you two via email. However, I just say that the icon does not go away regardless of the number of times the cartridge is updated.

[+intvsteve]

There are two different areas the "warning" icon may appear:

• The ROM list (the flat list on the left hand side of the UI)
• The Menu Layout (the tree on the right hand side of the UI)

You will only see the "warning" icons in a few special circumstances in the menu layout - most common is if you have your LTO Flash! connected and do a "preview" of what will change when you sync your menu to the cart. When you see the yellow triangle ​​on the right hand side​ it means that "This item (folder, ROM, manual) is different on your local machine than it is on your cart, and will be updated when you sync."

 

You will see the "warning" icon in the ROM list (left hand side) when a combination of two things happens:

• The UI is configured to "Validate ROMs on startup" (can't recall the exact wording). This is ON​ by default, but can be turned off in the ROM list settings.
• A ROM in your ROM list is modified after you've added it to the list of ROMs (LEFT hand side) and you have restarted the UI software.

The ROM list is stored as an XML file in "Documents/LTO Flash" and if you look at the XML, you will see that it stores CRC32 values for the .BIN and the .CFG (for those types of ROMs), or just the CRC32 of the .ROM if it's that format.

 

There are at least three ways to work around this behavior until I decide how to mitigate it in some other way:

• Turn off the "Validate at startup" feature. Bonus: App launches faster because it doesn't recompute CRC32 values for all the ROMs in the list.
• Remove and re-add the ROM.
• Quit the UI and hand-edit the XML file's CRC32 values by hand.

Yeah, those last two really suck and you don't want to do them.

 

As far as what can be done in the UI implementation, there are a few options as well, and I'm open to suggestions.

• Stop caring about reporting that - only complain if a ROM actually goes missing.
• Offer a way for the user to say "I don't care, stop nagging at me about this"
• Just automatically update the values in the ROM list
• ???
• Profit!

[+Lathe26]

<p>

 

As far as what can be done in the UI implementation, there are a few options as well, and I'm open to suggestions.

• Stop caring about reporting that - only complain if a ROM actually goes missing.
• Offer a way for the user to say "I don't care, stop nagging at me about this"
• Just automatically update the values in the ROM list
• ???
• Profit!

Thanks, that clarifies things. In my case, the warning icon was in the left side ROM list.

 

My recommended improvement would be to add a right-click menu that let's the user select something that means "yup, I acknowledge I updated the ROM file", at which point the GUI removes the icon and updates the CRC value stored in the XML file. This lets the user easily update the CRCs one at a time. Maybe the menu text could just be "Dismiss warning".

[+Lathe26]

A slightly updated version has been posted in the original post.

 

No real code was changed. Instead, the build process was changed to use "ASM MEMATTR ..." instead of the previous "edit CFG file and run bin2rom.exe".

[+Lathe26]

Ok, $10 to the first person to post a screenshot or photo of the Easter Egg.

[+DZ-Jay]

 

Ok, $10 to the first person to post a screenshot or photo of the Easter Egg.

 

 

 

Send cheque or money order to me, in care of DZ-Jay.

[+Lathe26]

Keyboard Component support added (and tested on real hardware). Mostly, this was just to change the extra RAM from being at $8040 to $C040 since the Keyboard Component puts 10-bit RAM at $8000 - $BFFF.

Also, the build script was changed from a Windows CMD file to a unix Bash script (tested on Cygwin on Windows 10) to take advantage of the 'sed' command.

Note: at present a Cuttle Cart 3 is required to work with the Keyboard Component since the LTO isn't compatible (yet ).

[JohnPCAE]

I'm so glad I found this. Once I design the memory interface board for my Bird's Nest project, I'll need something on the Inty that lets me poke addresses to test it.

[carlsson]

@JohnPCAE Is this the kind of program you mentioned you were looking for in the Bird's Nest thread? Or at least a variant of it.

[JohnPCAE]

Yes, I think this would do the trick!

[JohnPCAE]

I'm running this on my LTO Flash to test my video overlay project and I'm seeing something weird. I'm using it to inspect memory in the D000-DFFF range as that's where I expose my video buffer. What I'm seeing looks a lot like bus contention: it looks like the boards are trying to output the memory contents, but the memory probe is always seeing $FFFF. Is it possible that the flash cart is forcing all the bits to 1? Is there something I need to define, say in the .cfg file, that tells the flash cart that range D000-DFFF is supplied by an external device?

 

*sigh* I think I found the problem. I had the dual-port ram mistakenly wired to always output high-Z to the Master Component. Time to order a board revision...

Edited November 18, 2019 by JohnPCAE