This is what I use to compile with.It outputs .bin, .hex, .83p, .8xp, .8xk, .8xu, and .rom. The args are...
Code: TIC83+ infile [outfile]
If you dont use an outfile, the default is a ti83+ program.The output is formatted according to the extension of the output file.
Heres the code for TIC83+
Code: @echo off
set tdir=%cd%
cd /d %~dp0\source
set PATH=%~dp0\bin;%PATH%
set out=..\%2
if #%2==# set out=..\%~n1.8xp
brass %1
if /I %out:~-3%==bin move %~n1.bin ..\%~n1.bin & goto Done
if /I %out:~-3%==hex goto CompOS
if /I %out:~-3%==rom goto CompOS
if /I %out:~-3%==8xu goto CompOS
wabbit %~n1.bin %out%
goto Done
:CompOS
bin2hex %~n1.bin %~n1.hex
if /I %out:~-3%==hex move %~n1.hex ..\%~n1.hex & goto Done
if /I %out:~-3%==rom hex2rom 83p %~n1.hex ..\%~n1.rom & goto Done
build8xu -t83P -k04 -m00 -n01 -h03 -o%~n1.8xu -f04.key 00:0000:%~n1.hex
del %~n1.8xu
move %~n1-signed.8xu ..\%~n1.8xu
:Done
if exist *.hex* del *.hex*
if exist *.bin* del *.bin*
cd /d %tdir%
for the complete folder layout and all the included binaries, I've submitted my compiler to the archives as TIC83+ in the Windows programs section
Um, it's not your compiler. It's your batch file that uses a combination of Ben Ryves and Brandon Wilson's code.
Quit being so literal, I think everyone knows what I mean
Credit is a big deal in the open source community.
SirCmpwn wrote:
Credit is a big deal in the open source community.
It's basically all we have, since we don't get monetary compensation for our years and decades of sleepless nights, bleary-eyed debugging, and painstaking care.
KermMartian wrote:
It's basically all we have, since we don't get monetary compensation for our years and decades of sleepless nights, bleary-eyed debugging, and painstaking care.
Well, not in the TI open source community anyway. There are quite a lot of people that get paid to work on open source projects, like Linux and friends.
Kllrnohj wrote:
KermMartian wrote:
It's basically all we have, since we don't get monetary compensation for our years and decades of sleepless nights, bleary-eyed debugging, and painstaking care.
Well, not in the TI open source community anyway. There are quite a lot of people that get paid to work on open source projects, like Linux and friends. Indeed, and since that's the arena in which we happen to be dealing, I'd call SirCmpwn's statement mostly valid. Reputation is of utmost importance, so if someone tries to unjustly attack that reputation, or use your work without credit, or or undo your hard work in building up a name in a community, you have a right to be quite angry at that kind of disruption and destructiveness.
I've been working on setting up the software restarts for my OS and am a little stuck the BCALL (rst 28h)
Firstly, I know the bcall works like
Code: rst 28h
.dw address
But when a restart is executed it jumps away from the current address so how can I still read the address after?Is the current address pushed onto the stack?
Secondly, WikiTI says that if bit 15 of the address is set, I need to map pages 1F/3F/7F into the location 4000h-7FFFh, reset bit 15, and add 4000h.Same if bit 14 is set only I should map 1B/3B/7B instead.So am I supposed to somehow map all 3 pages in or what?
Last, if neither bit 14 or bit 15 is set, it is treated as a branched command for an app.but WikiTI doesnt tell how to go about doing that
Anakclusmos wrote:
But when a restart is executed it jumps away from the current address so how can I still read the address after?Is the current address pushed onto the stack?
Yes. A restart is basically a call instruction shrunk down to fit into a single byte. You can pop the return address from the stack, read two bytes from it (the BCALL routine number) then push it back onto the stack having incremented it by two (you need to increment by two so that when your routine returns you jump back to the point *after* the routine number). What you then do with this routine number is up to you; WikiTI documents how the TI-83+ OS does it, but you implement it in any manner you so desire.
nvrmind if you read my last post.I understand loading the value now.
but how would I go about maping the 3 pages into 4000h-7FFFh?
Anakclusmos wrote:
nvrmind if you read my last post.I understand loading the value now.
but how would I go about maping the 3 pages into 4000h-7FFFh?
*Mapping. Just load the corresponding page value into port (6).
but how would I map 3 pages in same location?would I just...
hangon, couldnt I just make a vector with the commands somewhere the map it to 4000h-7FFFh.Thats basically what they're doing, right?
Oh, those 3 pages are for the different calc models. For example, 1F on TI-83+, 3F on TI-84+, 7F on TI-83+SE/TI-84+SE
thanks for clearing that up.
I think I make the ION, MOS, and other misc shell routines as bcalls, but keep the bcall vectors page normally mapped there, so apps can use bcall to call them, and you should still be able to normally call them from programs.
Anakclusmos wrote:
thanks for clearing that up.
I think I make the ION, MOS, and other misc shell routines as bcalls, but keep the bcall vectors page normally mapped there, so apps can use bcall to call them, and you should still be able to normally call them from programs.
What you're really trying to say is make the locations that programs call map to bcalls into other parts of your OS, which is more or less exactly what Doors CS does within its three pages, if I'm understanding you correctly.
no.I'm going to put the ION, MOS, DCS, etc routines in the bcalls vector table.the page having this table will almost always mapped to 4000h-7FFFh.Since the page is already in the right position, you can CALL them from programs, and BCALL them from APPS.This fixes a compatability issue and adds more functionality for people writing apps.
Anakclusmos wrote:
no.I'm going to put the ION, MOS, DCS, etc routines in the bcalls vector table.the page having this table will almost always mapped to 4000h-7FFFh.Since the page is already in the right position, you can CALL them from programs, and BCALL them from APPS.This fixes a compatability issue and adds more functionality for people writing apps.
If the vector table is going to be in 4000h to 7FFFh, then you'll have to use 0000h-3FFFh for the actual code pages, which means every single page will need its own copy of the RST routines and the interrupt. Personally, I think that's a fabulously bad idea.
*slap to my own head* in the TIOS, when BCALLs are run a specific page (1B if bit 15 is set, 1F if bit 14 is set for the TI83+) is mapped to the address 4000h-7FFFh, 4000h is added to the command address, and the command is called.Basically, all I'm doing adding the shell routines to the bcall command table, and mapping the bcall page before running a program.This would mean you can either CALL or BCALL the shell routines.
Question:
Can I implement more types of interrupts in the SysInterrupt, or would that cause it to crash?
Code: SysInterrupt:
exx
ex af, af'
in a, (04h)
bit 0, a
jr nz, HandleON
bit 1, a
jr nz, HandleTimer1
bit 2, a
jr nz, HandleTimer2
bit 4, a
jr nz, HandleLink
jr InterruptDone
It'd be cool to have system interrupt for grayscale
Hate to bump, but am having an issue.
I trying creating a new OS the other day and can't get the screen to turn on. I'm using the same OS header as shown earlier in this topic along with the routines. The code for the os is this:
Code: #include "OSHeader.inc"
LCDBuf = $8000
Start_of_OS:
call Sleep
ld hl, $FFFF
ld (LCDBuf), hl
ld hl, LCDBuf
call SafeCopy
mainloop:
ld a, skEnter
call CheckKey
jr z, Start_of_OS
jr mainloop
#include "routines.inc"
The "CheckKey" routine is my own direct input routine which I know works, and all the other routines I've either pulled from this topic or wikiti. I'm using Brass to compile and for linking I'm using os2tools and bin2hex from Dwedit's appdev package.
I don't understand this because this is the same exact way I started Asylum, which I had no problem with. If someone could set me up with a small kit I'd be grateful