Jump to content


New Members
  • Content Count

  • Joined

Community Reputation

33 Excellent

About BillG

  • Rank
    Star Raider

Profile Information

  • Location
    North Tejas
  • Interests
    Programming and refurbishing vintage computers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Surprisingly, there is apparently no entry for the TMS9900 or 99/4A... http://www.99-bottles-of-beer.net/t.html
  2. This is a bit of a tangent, but... I have been working on a 8080 simulator to allow running CP/M programs on the 680x and 65[x]02. One of the posters on the forum at 6502.org said he is interested in what I am doing because he was "collecting languages" on his Apple II. Turbo Pascal was one of the compilers he mentioned; he did not say he had a Z80 card. That reminded me of my discovery long ago that Turbo Pascal for CP/M required a Z80 processor, both for running the compiler as well as for the programs it generated. I went back to MT+ or assembly language for things needing to run on an 8080 or 8085. But I also briefly considered trying to modify Turbo Pascal to generate 8080 programs; that effort did not go very far as programming on the then new IBM PC took up more of my time. I took a closer look at the CP/M version of Turbo Pascal after that discussion. I have since disassembled most of the run-time library and commented much of it. I still believe that creating a version of the compiler to run on an 8080 system is not feasible, but it now seems very doable to: * write an 8080 version of the run-time library * write a post-compiler to translate Z80 code generated by the compiler to 8080 assembly language * write a tool to stitch the two together If that can be done, it is not a huge stretch to * write enough of a Z80 simulator to run the Turbo Pascal compiler on processor X * write a version of the run-time library for processor X * write a version of a converter to translate Z80 code to processor X I believe this can be done with substantially less effort than writing a new Turbo compatible compiler to run natively on processor X
  3. Version 6 of Microsoft C was able to generate that compact interpreted code. It did not last that long, I think version 8 could not. Parts of Word 1.1 used it.
  4. Tinkercad is a very approachable way to get started in 3D design: https://www.tinkercad.com/ You add or subtract geometric shapes. Definitely give it a try. Somewhat more advanced is OpenSCAD, a parametric design tool. It is somewhat like programming. https://www.openscad.org/ Both of these are free to use. At the other end of the spectrum, more powerful and difficult to learn, are the full-featured "professional" CAD programs.
  5. In the new year, I hope to have my compiler technology far enough along to compile Pascal and Python solutions for the 7's problem. And hopefully, they will be competitive speed-wise.
  6. EhBASIC is derived from Microsoft BASIC. http://forum.6502.org/viewtopic.php?f=5&t=6194
  7. Something like Github may be good in case somebody wants to make improvements to it.
  8. I am steering away from Microsoft BASIC because it is still under copyright protection. I do not want to risk putting effort into something then be told I cannot use it.
  9. My head is spinning and this is how I plan to make it stop. 1. I choose this as the authoritative document. Appendix A of: https://ia801205.us.archive.org/14/items/bitsavers_tiTMS9900MstemDevelopmentManual1977_4482262/MP702_TMS9900_Family_System_Development_Manual_1977.pdf 2. It speaks in terms of machine cycles. A machine cycle consists of two clock cycles. This was a source of much of my confusion as some numbers appeared to be off by half or double. They were. 3. My assembler will distinguish only between workspace accesses and all other memory accesses (including instruction opcode and immediate operand fetches) and allow specifying whether each is in fast or slow memory. It will assume a 99/4A platform in which all slow memory accesses incur a penalty of four additional clock cycles. The default is fast workspace and slow other memory.
  10. Do you think this will be effective for writing emulators for other processors? My understanding is that the fastest non-jit approach is some form of threaded code instead of a central decoder/dispatcher.
  11. In your opinion, is it accurate?
  12. I have been playing with code generation on different processors. This line of code W0 := S1; sign extends a byte into two. For the 6502: 00037 ; 1 L v S1 0029 A0 00 [2] 00038 ldy #0 002B A6 16 [3] 00039 ldx S1 002D 10 01 (0030) [2/3] 00040 bpl 2f 002F 88 [2] 00041 dey 0030 00042 2: 0030 98 [2] 00043 tya 00044 ; 0 := v W0 -> 1 0031 86 0D [3] 00045 stx W0 0033 85 0E [3] 00046 sta W0+1 For the 6800: 00037 * 1 L v S1 0029 4F [2] 00038 clra 002A D6 16 [3] 00039 ldab S1 002C 2A 01 (002F) [4] 00040 bpl 2f 002E 4A [2] 00041 deca 002F 00042 2: 00043 * 0 := v W0 -> 1 002F 97 0D [4] 00044 staa W0 0031 D7 0E [4] 00045 stab W0+1 For the 8080: 00037 ; 1 L v S0 0100 3A 0015 [13] 00038 lda S0 0103 6F [5] 00039 mov L,A 0104 17 [4] 00040 ral 0105 9F [4] 00041 sbb A 0106 67 [5] 00042 mov H,A 00043 ; 0 := v W0 -> 1 0107 22 000D [16] 00044 shld W0 For the 9900: 00043 * 1 L v S1 0052 D020 0037 00044 movb @S1,R0 0056 0880 00045 sra R0,8 00046 * 0 := v W0 -> 1 0058 C800 002E 00047 mov R0,@W0 For the 68000: 00009 ; 1 L v S1 00000400 1038 0421 00010 move.b S1,D0 00000404 4880 00011 ext.w D0 00012 ; 0 := v W0 -> 1 00000406 31C0 0418 00013 move.w D0,W0 That almost feels like cheating. It is interesting that the last four examples have each been ten bytes long. Real cheating would be the 80386: movsx AX,[S1] mov [W0],AX For the AVR: 00011 ; 1 L v S1 000060 9160 0116 [2] 00012 lds R22,S1 000062 2F76 [1] 00013 mov R23,R22 000063 0F77 [1] 00014 lsl R23 000064 0B77 [1] 00015 sbc R23,R23 00016 ; 0 := v W0 -> 1 000065 9360 010D [2] 00017 sts W0,R22 000067 9370 010E [2] 00018 sts W0+1,R23 And finally, for the 6809: 00037 * 1 L v S1 0029 D6 16 [4] 00038 ldb S1 002B 1D [2] 00039 sex 00040 * 0 := v W0 -> 1 002C DD 0D [5] 00041 std W0 which brings up one of my favorite programming jokes: The Motorola 6809, where SEX is sometimes followed by STD. Thank you very much. Drive safely...
  13. I forgot that I also started PL/M compilers for the 6800 and 6502.
  14. Even though it is a challenge and I love a challenge, I am getting somewhat discouraged about trying to generate good code for the 9900. Are any of the emulators accurate in counting machine cycles?
  • Create New...