The VICMON cartridge has the same basic features and some for single step execution...but I did notice one space saving coding feature which used two bytes to store each of the three character nmemonics. It used 5-bits per character and a routine to convert each pair of bytes to the three byte nmemonic for displaying.
Funny how that mnemonic technique gets around. Here's the mnemonic table from Supermon 816:
Code: Select all
; sorted encoded mnemonics...
;
mne_xba =$10f2 ;XBA
mne_lda =$115a ;LDA
mne_pea =$11a2 ;PEA
mne_pha =$1262 ;PHA
mne_pla =$1362 ;PLA
mne_bra =$14c6 ;BRA
mne_ora =$14e0 ;ORA
mne_sta =$1568 ;STA
mne_txa =$166a ;TXA
mne_tya =$16aa ;TYA
mne_phb =$1a62 ;PHB
mne_plb =$1b62 ;PLB
mne_trb =$1cea ;TRB
mne_tsb =$1d2a ;TSB
mne_sbc =$20e8 ;SBC
mne_bcc =$2106 ;BCC
mne_adc =$2144 ;ADC
mne_tdc =$216a ;TDC
mne_dec =$218a ;DEC
mne_sec =$21a8 ;SEC
mne_clc =$2348 ;CLC
mne_inc =$23d4 ;INC
mne_tsc =$252a ;TSC
mne_bvc =$25c6 ;BVC
mne_tcd =$292a ;TCD
mne_sed =$29a8 ;SED
mne_phd =$2a62 ;PHD
mne_cld =$2b48 ;CLD
mne_pld =$2b62 ;PLD
mne_and =$2bc4 ;AND
mne_xce =$3132 ;XCE
mne_bne =$33c6 ;BNE
mne_wai =$50b0 ;WAI
mne_pei =$51a2 ;PEI
mne_sei =$51a8 ;SEI
mne_cli =$5348 ;CLI
mne_bmi =$5386 ;BMI
mne_rti =$5566 ;RTI
mne_phk =$6262 ;PHK
mne_brk =$64c6 ;BRK
mne_jml =$6b96 ;JML
mne_rol =$6c26 ;ROL
mne_bpl =$6c46 ;BPL
mne_brl =$6cc6 ;BRL
mne_asl =$6d04 ;ASL
mne_jsl =$6d16 ;JSL
mne_rtl =$6d66 ;RTL
mne_wdm =$7170 ;WDM
mne_mvn =$7ddc ;MVN
mne_rep =$89a6 ;REP
mne_sep =$89a8 ;SEP
mne_php =$8a62 ;PHP
mne_plp =$8b62 ;PLP
mne_cmp =$8b88 ;CMP
mne_jmp =$8b96 ;JMP
mne_cop =$8c08 ;COP
mne_nop =$8c1e ;NOP
mne_stp =$8d68 ;STP
mne_mvp =$8ddc ;MVP
mne_beq =$9186 ;BEQ
mne_per =$99a2 ;PER
mne_eor =$9c0c ;EOR
mne_ror =$9c26 ;ROR
mne_jsr =$9d16 ;JSR
mne_lsr =$9d1a ;LSR
mne_bcs =$a106 ;BCS
mne_tcs =$a12a ;TCS
mne_rts =$a566 ;RTS
mne_bvs =$a5c6 ;BVS
mne_txs =$a66a ;TXS
mne_bit =$aa86 ;BIT
mne_clv =$bb48 ;CLV
mne_tax =$c8aa ;TAX
mne_ldx =$c95a ;LDX
mne_dex =$c98a ;DEX
mne_phx =$ca62 ;PHX
mne_plx =$cb62 ;PLX
mne_inx =$cbd4 ;INX
mne_cpx =$cc48 ;CPX
mne_tsx =$cd2a ;TSX
mne_stx =$cd68 ;STX
mne_tyx =$ceaa ;TYX
mne_tay =$d0aa ;TAY
mne_ldy =$d15a ;LDY
mne_dey =$d18a ;DEY
mne_phy =$d262 ;PHY
mne_ply =$d362 ;PLY
mne_iny =$d3d4 ;INY
mne_cpy =$d448 ;CPY
mne_sty =$d568 ;STY
mne_txy =$d66a ;TXY
mne_stz =$dd68 ;STZ
Structurally, it's the same as used in the C-128 monitor, Supermon 64 and Supermon for PET/CBM machines, and has been attributed to Jim Butterfield. VICMON was a derivation of Supermon, so you know whence the idea came.
Aside from saving storage, the 3-for-2 encoding scheme can make mnemonic look-up run faster, as only two characters need to be compared, which is tailor-made to the 65C816 and its ability to atomically compare 16 bit values. As I have the table sorted in ascending order, I can locate any given mnemonic with a binary search. There are 92 mnemonics in the '816's assemble language and the worst-case binary search time on an ordered list is described as
log2 (N), where
N is the number of elements in the list. So no more than seven comparisons would need to be made to determine if a mnemonic entered during instruction assembly is valid.
A binary mnemonic search is an unnecessary luxury in a machine language monitor, as code assembly is manual and happens far faster than one can type. Ergo I ended up using a linear search in Supermon 816, as the resulting code takes up less space. However, in an assembler working with a source file, a binary or hashing search algorithm would be essential to getting the job done as quickly as possible.
I later moved up to the C64 and bought their macro assembler/linker/editor package which also featured the same monitor code with two versions at different addresses ($8000 and $C000).
That was Supermon 64 with some cosmetic changes that Commodore shipped with MADS. The first version of the assembler had some sort of problem correctly parsing macros, but that was later fixed. I used MADS a lot before switching to the C-128 and the DEVPAK package.
Fred Bowen almost ported MADS to the C-128 to run in 128 mode, but abandoned the project when it was decided to port the VAX 11/780 6502 cross-assembler that Commodore had used to develop the 128's kernel. That assembler became the core of DEVPAK, along with the horrible editor that shipped with it. Like most DEVPAK users, I ended up using a different editor to write my source code and later on used Craig Bruce's
ZED-128 editor, which although never fully completed, worked very well. Hedley Davis, the CBM programmer who spearheaded DEVPAK, was dismayed to find out that no one liked his editor (it was as unfriendly as a hungry lion) and dismissed all the critics as incompetents who had never worked with a real computer. I guess Commodore was just selling toys.
It's remarkable that you're willing to tell us a technique deployed by MOS Technology and used by thousands of KIM-1 owners wouldn't work. KIM-1 is a different context than POC, but your comments about the need for logic analyzers and 'scopes have no bearing in either case -- you don't seem to have grasped the point, and were perhaps talking about something else entirely (maybe your "circuit to do it with POC at one time, but it wasn't trivial").
