Hi…I am 44 and from Eastern Europe, so I experienced some of 8-bit computers in late 80’s as a teenager. I have never heard of 8-bit Apple nor S100 computers till few years ago when I started to discover US computers. And I like it much. I built most of the N8VEM boards, SCELBI 8H replica, Cosmac Elf 2000 and SBC6120+IOB6120+FP6120 by Spare Time Gizmos. I used to use CP/M on Z80 Sharp MZ-800 and play games on my friends’ ZX Spectrum, Atari 800XL or Commodore C64. The Sharp MZ-800 is still my favorite computer and there is quite a lot going on here around it. We created some interface replicas and there is Unicard emulating floppy, RAMdisk and Quick Disk interfaces, adding VGA and Ethernet to this old computer.
1 Like
If you are into replicas, you might be interested in this site: https://obsolescence.wixsite.com/obsolescence
I have some of his kits and they are great.
One of the bugs in the 6502 version of Space Voyage was not in its code but a couple of the obscure forms of the ADC instructions in my emulator was inadvertently ignoring the carry flag…
1 Like
That subroutine turns out to be flawed. A set carry flag when beginning the adjustment indicates that the preceding add overflowed the upper nybble. The carry flag needs to remain set after the adjustment even if adding the correction factor does not set the carry flag.
Edit: The updated code…
000A24 02159 DAA:
000A24 E070 [1] 02160 ldi R23,0 ; Initially no correction factor
02161
000A25 E0A0 [1] 02162 ldi R26,0 ; Presume carry flag is clear
02163
000A26 F410=000A29 [1/2] 02164 brcc DAA_NotUCarry ; The add overflowed the upper nybble?
02165
000A27 6670 [1] 02166 ori R23,$60 ; Correct upper nybble
02167
000A28 95A3 [1] 02168 inc R26 ; Remember original carry flag
02169
000A29 02170 DAA_NotUCarry:
000A29 F40D=000A2B [1/2] 02171 brhc DAA_NotLCarry ; The add overflowed the lower nybble?
02172
000A2A 6076 [1] 02173 ori R23,$06 ; Correct lower nybble
02174
000A2B 02175 DAA_NotLCarry:
000A2B EA90 [1] 02176 ldi R25,$A0 ; Upper nybble needs correction if over 9
02177
000A2C 2F86 [1] 02178 mov R24,R22 ; Make a scratch copy
02179
000A2D 708F [1] 02180 andi R24,$0F
02181
000A2E 308A [1] 02182 cpi R24,$0A ; Check if lower nybble is out of range
000A2F F010=000A32 [1/2] 02183 brcs DAA_CheckUpper
02184
000A30 6076 [1] 02185 ori R23,$06 ; Correct out of range lower nybble
02186
000A31 E990 [1] 02187 ldi R25,$90 ; Upper nybble needs correction if over 8
02188 ; with carry from lower nybble
02189
000A32 02190 DAA_CheckUpper:
000A32 2F86 [1] 02191 mov R24,R22 ; Make a scratch copy
02192
000A33 1789 [1] 02193 cp R24,R25 ; Check if upper nybble is out of range
000A34 F008=000A36 [1/2] 02194 brcs DAA_Add
02195
000A35 6670 [1] 02196 ori R23,$60 ; Correct out of range upper nybble
02197
000A36 02198 DAA_Add:
000A36 0F67 [1] 02199 add R22,R23 ; Do decimal adjust
02200
000A37 F008=000A39 [1/2] 02201 brcs DAA_Carry ; Done if carry set
02202
000A38 95A6 [1] 02203 lsr R26 ; Restore original carry flag
02204
000A39 02205 DAA_Carry:
000A39 9508 [2] 02206 ret
1 Like
Space Voyage for the AVR is now feature complete. Lots of testing is needed on all of the versions to check that the results match.
It has been almost a year, but I finally got over the mental block to working on the variable-length integer code and finished up right shift. Next up is left shift; that will open the door to much needed testing as it is a way to make very large numbers very quickly.
After that is more work on exception handling by modifying the run-time code to raise exceptions for fatal errors. Only divide by zero is currently hooked up.
And finish the AVR heap manager now that I got my sea legs back on AVR assembly language.
Looking forward, what should be done next?
- Develop a way to easily generate binaries for various 6502 computers?
- Write heap managers for more processors? Which ones? x86? ARM? 68000? 9900? 1802?
- Start compiler modifications to target the other existing heap managers?
- Implement Space Voyage on more processors? Which ones?
- Begin work on lists and tuples?
- Figure out iterators?
- Something else?
Left shift is starting to work for simple cases but it is still quite buggy for larger numbers…
The following code
s = ''
i = 0
while s == '':
print("1 <<", i, "->", 1<<i)
i = i + 1
s = input('Next... ')yields this result
The time needed to do the shift and format the result for display is noticeable, but much less than one second. Edit: this is running in my emulator. Using real hardware will be much slower.
2 Likes
Dumping the heap shows that the above test is not leaking memory.
The first column is the address of the memory block.
The second is the address of the next block.
The third is the length of the block, not counting the header.
The fourth is 0 if the block is free, $FF if it should not be freed and the reference count otherwise. The first and last blocks are sentinels marking the ends of the heap.
A minority, likely niche, request is the 9900. Target machine would be TI 99/4A.
1 Like
I have been studying the 9900, but am not quite ready to try writing code for it yet.
It will be worth doing Space Voyage for it first before committing to a Python target.
By “doing Space Voyage” for it (9900), do you mean transcoding the 6800 assembly into 9900 code, as you’ve done for other targets?
Do you have the Space Voyage 6800 source code, or just the object/S19?
1 Like
Yes. It is both big and complex enough to get a good feel of programming on a platform.
It was sold in two forms, a cassette tape or a print of the source listing and S19 hex. I have both. Some years back, before OCR was cheap and reliable, I had typed in the source code.
If you’d be willing to send me a copy of your Space Voyage source code, I could start the transcoding process to the 9900. This would have to be done as a background process, as I have (too many) other projects ongoing. Would likely use an existing 9900 emulator for development, as well as the python-based 9900 development tools referenced in topic posts 185 & 186 in this thread.
The motivation is multi-fold
- learn more about interpreters, parsing, compilers
- refresh and add to my limited python skills
- help to bring python capability to the still-active TI-99/4A community (who hang out at AtariAge)
I’ve done a few 6800 projects, but it was back in the 80’s. While in college, I did a design to convert a surplus IBM Selectric-based terminal to a ‘letter quality’ printer. The printer was then to be connected to a North Star Horizon CPM machine via serial port. Replaced the non-working DTL logic boards with 6800-based wire wrap board. All development was on a Heathkit ET-3400 6800 trainer board. No assembler, all hand assembled and entered via ET-3400 keypad. At least I got to hand enter the code in hex instead of binary 
.
Other project was model airplane engine controller using a 68HC05. Done for, and in conjunction with, one of the electronic techs at TI who had a TTL counter based design. Microcontrollers weren’t in his wheelhouse, so we collaborated. At least I had a PC-based cross assembler for this project.
1 Like
Sending a PM…
I downloaded the toolset you suggested, but stopped when it said it required Python 2.7. I am running 3.something and did not wish to deal with a second installation.
What emulator do you recommend?
I understand your reluctance to muck up your system with a legacy version of python. What draws me to the xtd99 tool set is the support for the TI99/4A platform, for which there are several good emulators available to test any new programs. I haven’t actually used it, but will be giving it a try soon. BTW, what OS do you use for development?
Regarding emulators, I like Classic99 because it has a debugger. It was written by Tursi, who’s one of the top-notch developers of new TI 99/4A software and hardware. And it plays Parsec very well 
I’ve just dabbled occasionally in 99/4A stuff since the 90’s, not done any hardcore development. The following discussion references tools that can be found on the AtariAge page referenced at the end of this post. This link is in an earlier post in this thread, but is given here for convenience.
I’ve used Dave Pitt’s ASM990 most recently. It’s macro assembler that can generate code for TI’s 990 minicomputer line. There’s also a cross linker as well as a simulator for various 990 minis.
For targeting code to the 99/4A platform, it might be better to use a linker that was written with this platform in mind. In reviewing the tools available, the XA99 assembler and L99 linker by Fred Kaal are something I’m going to look into. The L99 linker has many commands specifically to support the Ti99/4A and Geneve platforms. Fred is another of the longtime 99/4A developers who’s contributed heavily to the what is available today.
I’ll kick the tires on some of these tool and report back my experiences.
1 Like
Because much of this stuff started so long ago, it is DOS based.
Because I like Borland’s Turbo Debugger so much, I continued to develop with Borland tools in DOSBox.
Several years ago, I embarked on a “modernization” program since 64-bit versions of Windows refuse to run 16-bit code without resorting to emulation. It involved reimplementing my subroutine library, much of which was in assembly language for speed and size, and modifying the code to use the Win32 API instead of DOS calls (int 21h.) I wrote a special library to allow building a DOS version; it puts Win32 wrappers over DOS calls.
I bought a TI 99/4A when they had the the $100 rebate offer and only played games on it. Shortly after I moved to the Metroplex, much of the 99/4A stuff was being clearanced by what used to be the Albertson’s store at Valley View and Josey. I bought up quite a bit of it for my brother and myself, including the expansion box. I never had time to get serious programming it.
When I moved, it was all packed up and never unpacked. It is now buried under other stuff.
The 990 was a strange beast. The system I used had memory-mapped video terminals which provided instantaneous screen updates (and a special command to spy on another user.) Instead of commands, it used proc (script) files which “bid tasks” to run binary programs. I have fond memories of that machine.
Please do…
<drumroll>
After some research and deliberation, the next target for a Space Voyage clone is the Motorola 68000, namely the Atari ST platform.
Why the 68000? It is a processor I have worked with but have not written a substantial amount of assembly language code.
Why the Atari ST? Unlike the Macintosh, I can create an old-style command line “console” program. Unlike the Amiga, the operating system is very simple (DOS like) and the file formats are well documented.
3 Likes
Nice! those actually ran both minix and vim. Well ok a vim clone.
Plus those artually powered a good few good BBSes, demoscene and warez.
Looks like ebay has a few for around $300 or so.
Doubt that’s something one can see acquired anytime soon without any fundraising but its on the radar.
Space Voyage for the 68000 is beginning to come to life…
2 Likes
I have mentioned before that some processors clear the carry flag when a logical operation (and, or, xor) is done.
The 68000 logical operations clear the carry; those of the previous 6800/6809 processors did not. It is not clear why they made that change. What they did do was provide another status flag, X, which tracks carry for the most part, but is not cleared by the logical operations. Typical operations which consume the carry such as add, subtract and bit shifts now use the X flag.
But there are still some problems:
- There are no conditional branch instructions which test the X flag.
- Motorola did away with the increment and decrement instructions, replacing them with slightly more general “add quick” and “subtract quick” instructions which take a number from 1 to 8. But they are add and subtract instructions, both affecting the carry and X flags. Increment and decrement on most processors leave the carry flag alone.
1 Like