Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

110 Excellent

About xahmol

Profile Information

  • Gender
  • Location
    Utrecht, the Netherlands
  • Interests
    Retro computers, technology, cloud arhitecture, IT security, IT audit
  • Currently Playing
    Civilization VI, M.U.L.E.
  • Playing Next
    My own developed retro game ;-)

Recent Profile Visitors

90 profile views
  1. Thanks Matt, see you updated on Github for these changes. Did a make clean and then a rebuild with my own build.sh script containing all path exports, and now works flawlessly (after realising to place the make command also in the build script as the pywiz.sh needs also the path export).
  2. Works. Updated amongst other my window border draw, pull down menu and clear area routines (so basically all routines that had for loops in them using vdpchar() before). Noted also that VDP_SET_ADDRESS_WRITE(pAddr); and VDPWD=ch; do not update the cursor for conio.h and vice versa, so if you mix this with conio output functions you have to set cursor positions seperately. Have indeed the feeling that the updated routines are now indeed noticably quicker, so thanks. Uploaded a new version as ZIP in the start post.
  3. Thanks for the explanation Tursi, will probably use that if I ever want to make something TI specific. For this board game, anything faster than BASIC is quickly quick enough 😉 so there I prefer to keep code cross platform enabled to the largest extent possible. But I might actually use VDPWD for the drawing of the window borders as I could not use cputc() there anyway (border graphics are in those below 32 patterns). Also that is about the only place where I think an increase in speed would actually be noticeable to the user in my program. And just to check if I understand this correctly: how would I set the start x,y position for VDPWD to start with? I see it defined in vdp.h as #define VDPWD *((volatile unsigned char*)0x8C00) So would pointing it at a different x,y position just be putting gImage+VDP_SCREEN_POS(r,c) somewhere? Edit: never mind, already found I assume: VDP_SET_ADDRESS_WRITE(pAddr) At least that is what the vdp_char.c source does: #include "vdp.h" void vdpchar_default(int pAddr, int ch) { VDP_SET_ADDRESS_WRITE(pAddr); VDPWD=ch; } void (*vdpchar)(int pAddr, int ch) = vdpchar_default;
  4. Original question was how to detect from software.
  5. Haha, well, C is old and mature, but C on 8 bits with cross compilers much less so 😉 CC65 is relatively mature for Commodore targets. But many other targets are fairly recent. And also C cross compilers on the TI are a fairly recent thing if I read this forum, with libs getting developed basically by the need of somebody who misses them while programming. So it’s getting there, but you always encounter surprises coming from target to another target. But honestly, that is a large part of the fun doing it 😉and coping with playtesting the same game all over again. The fun is solving problems you encounter on a new target, if just copy paste compile for new target would work all the fun would be gone.
  6. Added new version which I hope could be the release version. See ZIP and changelog in startpost. Added speech and boottracking.
  7. But that reminded here: instruction to the user is simple. If you have this between console and TV you have PAL....😉
  8. Same here 😉and know that even as a kid I was making fun of Never The Same Color.....
  9. Are you sure? Every single serious Commodore user knows exactly if he (or sometimes she) has a PAL or NTSC. And for the TI: I am pretty sure that the ones having a PAL would know, so you could just say to the user if you don’t know, use NTSC. Also, the target group of people still using the TI and know how to get new software from it from here probably is significantly more knowledgable than the generic home computer owner of the past would be. And if it is a simple toggle, a user can just try both and see what gives best results.
  10. You could of course also let the user select PAL or NTSC.
  11. Sorry, it is indeed not the path, but the hostname, typed too quickly. See the hightlights in yellow below (and compare to parameterised hostname in the first three lines): scp FC/LOAD [email protected]${TIPI_HOST_NAME}:/home/tipi/tipi_disk/FC/LOAD scp FC/FCMD [email protected]${TIPI_HOST_NAME}:/home/tipi/tipi_disk/FC/FCMD scp FC/FCMDXB [email protected]${TIPI_HOST_NAME}:/home/tipi/tipi_disk/FC/FCMDXB scp example/gcc/ftp/FTP [email protected]:/home/tipi/tipi_disk/FC/BIN/ scp example/gcc/say/SAY [email protected]:/home/tipi/tipi_disk/FC/BIN/ Well, I Googled the error message I got and got this: https://stackoverflow.com/questions/53836858/shell-function-in-gnu-makefile-results-in-unterminated-call-to-function-shel So I am apparently not having the only environment needing that # to be escaped.
  12. Checked out the new makefiles and scripts. Maybe it is work in progress (so maybe I just was too early), but encountered a few small things: main Makefile, line 12: VER:=$(shell grep "#define APP_VER" b0_main.h | cut -d '"' -f2): Changed that to VER:=$(shell grep "\#define APP_VER" b0_main.h | cut -d '"' -f2) So escaped the #, as at least at my side I got an error as my WSL Ubuntu install ignored everything after the # as comment, including the final ) (which gave the error message). Might be that this different behaviour is caused by me using this under Windows 10 WSL (using Ubuntu). Had two other issues that I had to solve with dos2unix as well (encountered this: https://askubuntu.com/questions/966488/how-do-i-fix-r-command-not-found-errors-running-bash-scripts-in-wsl ) In the deploy.sh script now all pathnames are parameterised, apart from the last two scp commands to copy to TIPI (the other SCP commands to TIPI are parameterised allready) Makefile and pywiz.sh of the SAY example are not parameterised yet, needed to change paths to python_wizard and Classic99 DSK1 dir still Regarding the Makefile of that SAY example: it includes a copy to that Classic99 DSK1 dir which I would now expect in the deploy script, not here For the rest works great, so many thanks! (and learning more about Linux scripting under WSL Ubuntu along the way )
  13. It does handle control codes, but that was exactly what I was not expecting it to do And unsure if it is an incorrect implementation of conio on the Oric Atmos target or not, but it was pretty handy to be able to use cputc to just copy an attribute code to the screen instead of the ASCII control code for the codes under 32. Just did check the CC65 reference documentation, and I actually think you are right. It does not explicitely say so, but as it states there that it supports \n and \r, I am now pretty sure that indeed cputc is supposed to output the control code instead of just copying the value itself to the screen position. 'Like all other conio output functions, cputc distinguishes between \r and \n.' https://cc65.github.io/doc/funcref.html#cputc Then it is just a damn handy incorrect implementation on the Atmos target of conio.h..... Actually curious now what it then does on the Commodore 64/128 target. On Atmos target, behaviour of cputc is indeed different.... but tend to agree with you now that is actually an incorrect implementation. Hope now they never correct that Atmos implementation as that would directly break my code, used it extensively to copy color attribute codes to the screen which on the Oric are values under 32 and take a character position instead of going to separate attribute memory...... Funny how every retro computer has its completely different quirks to handle color. You really never can make assumptions coming from another target. Anyway: I then assume that vdpchar() is really the only correct way to print user defined patterns numbered under 32? Not really a problem, just needs vdpchar(gImage+x+32*y,c) instead of just cputcxy(x,y,c). And need of reminding yourself that vdpchar() does not take care of the cursor position so is only a cputcxy replacement and not a cputc.....
  14. Super! And did encounter the pywiz.sh indeed already, was the one that took me the longest to find where that path error I got came from Have python_wizard at a slightly different path than you have. And of course I won't hold you liable for anything that breaks by me using your unreleased stuff.....
  15. Check. But I actually liked the build script to copy everything to Classic99 and TIPI automatically
  • Create New...