Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


mobluse last won the day on November 23 2020

mobluse had the most liked content!

Recent Profile Visitors

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

mobluse's Achievements


Explorer (4/14)

Conversation Starter Rare Dedicated Rare First Post Collaborator Rare Reacting Well Rare

Recent Badges



  1. POP also exists in AtariBASIC: "If a GOSUB does not have a RETURN, for instance, the stack will still hold the return address. This can be cleared with a POP so as not to cause confusion later. It must be used in the execution path of the program, and must follow a GOSUB not using a RETURN. It is normally the sign of a badly designed program, but is useful in debugging." https://www.page6.org/archive/issue_16/page_43.htm You cannot change the machine stack pointer from BASIC so you need a machine code routine. If it is possible to read the stack pointer from BASIC you could GOSUB 99, swap the two top elements using PEEK and POKE, update the top element to the next next line in BASIC using PEEK and POKE and RETURN twice. That would have the same effect as POP or SYS699 in the program below. Maybe some other solution without machine code is possible. A person in a Swedish C64 forum (commodore64.se that's offline), bjonte, solved the problem using machine code for C64 and VIC20: bjonte used https://archive.org/details/Compute_s_Mapping_the_Commodore_64 and https://archive.org/details/COMPUTEs_Mapping_the_VIC_1984_COMPUTE_Publications as references. POP comes from Apple Integer BASIC by Steve "Woz" Wozniak, and then the later floating point Applesoft BASIC was made backwards compatible with that. Anyway, now it is possible to port some Applesoft or Atari BASIC programs with POP to C64 or VIC20. How is POP useful in debugging?
  2. Which version of x16emu does Commander X16 Bot (@x16bot) run now?
  3. I received BASICODE 2 for C64 and X16 and when I added these routines to BASICODE2 I could run aritm-bc3c.bas in x16emu: 450 OT=TI:SD=60*SD/10 451 GOSUB 200:IF IN$="" AND TI-OT<SD THEN GOTO 451 452 SD=0:RETURN 950 CC(0)=7:CC(1)=0:GOSUB 100:END
  4. Also SHY i.e. CHR$($AD) is not reachable. I didn't read all of this article, but one could type SHY (Syllable HYphen) at the end of a line to indicate that this hyphen can be removed, i.e. a sort of line-continuation character for words: https://jkorpela.fi/shy.html NBSP i.e. CHR$($A0) is reachable.
  5. There are still some characters that cannot be typed in ISO mode AFAIK: ¬¹²³. BTW this Mac keyboard layout is called U.S. Extended or ABC Extended; not just U.S. or ABC because that is a slightly different layout with some AltGr dead keys on other positions.
  6. Doesn't work in EN-US United States (with Mac extensions): Alt+; = × Alt+X . (Alt+x followed by space gives .; Alt+x seems to be a dead key.) Alt+, ␣ , Alt+. ␣ . These should work according to https://github.com/commanderx16/x16-docs/blob/master/X16 Reference - 02 - Editor.md The only real problem is how to type × (multiplication sign, $D7). I found this helpful page: https://sites.psu.edu/symbolcodes/mac/codemacext/ In Linux a similar map is English (US) - English (Macintosh): setxkbmap us mac That is not exactly the same U.S. Extended in macOS: https://askubuntu.com/questions/292729/keyboard-layout-identical-to-us-extended-on-macbook-pro
  7. SCREEN -1 and SCREEN $FF work now as they should when I use the current source from GitHub in Raspberry Pi OS Buster. I can not test r41rc1 in Raspberry Pi OS since it is not compiled for ARM and there is no source.
  8. SCREEN -1 doesn't work here in Linux (Raspberry Pi OS Buster) when compiled now from current source. SCREEN $FF works, but changes the colors to default (white on blue) instead of keeping the colors like it does when you use SCREEN 3 or SCREEN 6. I tried to use SCREEN $FF in order to make a version that works both in R38 and R41 and later.
  9. There seems to be a bug in R41 RC in Linux (Raspberry Pi OS Buster) concerning automatic line breaks when you run a simple test program in SCREEN 6 (20x15 text mode). Each third line is blank when it prints 4 digit numbers. You can hold down Ctrl to make it scroll slower. 10 SCREEN 6 60 N=0 70 PRINT N; 80 N=N+1 90 GOTO 70 This was fixed in some earlier experiment: Paste the program after SCREEN 0 or SCREEN 3, because when you paste in SCREEN 6 mode the program is corrupted and only some lines are retained. This seems to be another bug.
  10. I found a way to test my mental calculation training program Aritm for X16, C64, VIC20, ZX81, Apple I, PicoMite and other BASIC computers using Pexpect which is a system for automating logins etc. Pexpects is a Python module, but similar systems exist for other programming languages e.g. Expect for Perl. For X16, C64, and VIC20 I didn't use actual computers or emulators, but a C64 BASIC for console: cbmbasic: https://github.com/mist64/cbmbasic. I only tested one actual computer using USB serial: PicoMite. I tested the ZX81 and Apple I versions using emulators. I converted the X16 BASIC version to cbmbasic using: sed 's/#1,/ /' aritm-x16.bas > aritm-cbm.bas and commented one line that had incompatible commands that only affected colors, screen size, and input prompt. cbmbasic doesn't support removing BASIC prompt using a file handle, but does using a poke, but I tried not to use pokes to make the program less dependent on a particular machine. The test program is currently configured for cbmbasic and Aritm versions for X16, C64, and VIC20 are tested with the same configuration: https://github.com/mobluse/aritmjs/blob/master/expect-aritm.py The test configures Aritm to generate all problems and then answers them, but let you answer the last. In order to speed up testing one can change the delay subroutine in the BASIC program. BASIC dialects are rather incompatible with regards to e.g. precedence rules and floating point precision; so it's important to test. You wouldn't want a program that is supposed to teach you mental calculation to teach you the wrong facts. One could use the official X16 emulator, but that was more difficult to input to since one would have to send key presses to the emulator window, but that is also doable using another Python module, but I have not tested it with x16emu. For future testing it would be good if the real X16 had a serial port, but if it doesn't one could send key presses using the PS/2 port and get output to Expect using e.g. morse or DTMF tones from the sound system or QR codes on the screen.
  11. I guess most people in other countries have a keyboard suited to their language, but programmers often use US keyboard since it has faster access to keys common to programming languages. I think X16 would get critical reviews in the USA if the only US like layouts are US International and Polish Programmers, where Polish Programmers is the best since it only has one dead key: ~. I'm Swedish and used US International in Windows for years since 1994 when I could (i.e. on non laptops and I brought my own keyboard to work), but I think United States (International) with AltGr dead keys is better and it also doesn't irritate native US keyboard users since the dead keys require Alt Gr. In Linux you start this with: setxkbmap us altgr-intl. It's not built in to Windows, but e.g. this exists: https://github.com/thomasfaingnaert/win-us-intl-altgr Now I mostly use UK keyboard in Linux with the layout setxkbmap gb which works rather well also for Swedish and many other languages since it is already international. For US keyboard I prefer EurKEY: https://eurkey.steffen.bruentjen.eu/ That the PETSCII mode has no dead keys is good, but e.g. Forth uses most ASCII characters that are not in PETSCII, and e.g. a light-weight PHP or Python (e.g. Snek) might be ported to X16 and that might need ISO8859-15
  12. It's not a bug, but Linux additions which give more characters from ISO8859-15 on the keyboard (œ, Œ, ï, and Ï) and easier access to some that exist (' and ") without removing any characters since ´ and ¨ doesn't exist in ISO8859-15.
  13. There are some more characters in ISO8859-15 that are on the US International keyboard in Linux "setxkbmap us intl" and "setxkbmap us altgr-intl": œŒ on xX and kK with Alt Gr, ïÏ on jJ. It's a bit strange that œŒ are on two keys. US-International keyboard layout (Linux) also has ®® on vV and ëË on rR. I think one should at least have ®® also on vV since it is unused now, and that would open the opportunity to have ëË on rR later. When using "setxkbmap us intl" in Linux you can type ' using AltGr+' and " using AltGr+Shift+'. I think this is better than ' followed by space and Shift+' followed by space which are the only alternatives in Windows with US-International to type ' and ".
  14. I believe most of those that use US International use the version with AltGr dead keys. The standard US International with dead keys affects the normal use of ` ~ ^ ' ", which is bad for programming e.g. C-like programming languages and Forth. Now X16 has US International with dead keys. If you want to type " now you have to type " and space.
  15. PS/2 keyboards: 0000041D Swedish *3 (I would prefer 0000083B Swedish with Sami to the degree that can be implemented with ISO8859-15 characters.) 00000409 US *2 (I would prefer EurKEY, but US International with AltGr dead keys is OK.) Below keyboards work only in emulators, unless an adapter works: USB keyboards: 00000809 United Kingdom (I would like a layout similar to EurKEY.) 00000406 Danish Bluetooth keyboard: Nordic layout i.e. these on top of each other, but with different colors where there is conflict: 00000414 Norwegian (I think the Norwegian layout is best among the Nordic since it has | and \ easily accessible.) 00000406 Danish 0000041D Swedish 0000040B Finnish (Same as Swedish.) I have another bluetooth keyboard: 00000409 US, but with Å Ä Ö also printed on [ ' ; and that is supported in Linux ("Swedish - Swedish (US, with Swedish letters)"). I have laptops with Nordic layout; also for emulator use.
  • Create New...

Important Information

Please review our Terms of Use