Hello :uxn: foks!
Just updated uxngba with a much more performant ARM-UXN core. In addition to that, the last ppu changes have been implemented and there is a new system for loading roms, which now enable bank switching, meaning you can load bigger roms like Oquonie on it!
The new core makes it almost playable and I believe it could be locked at 60Hz if the graphics updated only every other frame (needs to happen on the TAL side)
https://git.sr.ht/~rabbits/uxn-gba
https://git.badd10de.dev/uxngba/
Bad Diode
in reply to Bad Diode • • •The new assembly core should be compatible with other ARM system with a few minor modifications (for example using the right .section directive, etc.).
https://git.badd10de.dev/uxngba/tree/src/uxn-core.s
Eager to see if it would improve the performance on the Playdate and raspberry pi ports 😀
There may still be room for optimization, but I'm quite happy with it for the most part. Let me know if you find errors or believe you could improve it in any way!
uxn-core.s\src - uxngba - A port of the UXN virtual machine for the GBA.
git.badd10de.devDevine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •monoxane
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Devine Lu Linvega • • •sooo how deep do you want me to go with this? I can setup the same build system I have for the gba so that we can include binary files directly (I think we are currently including the rom as a boot.c file, right?).
I can go nuts and just check out everything since there is no audio (yet), so only the main functions, build system and ppu to look at.
Do you want me to work on a separate branch or should I wing it on main?
Devine Lu Linvega
in reply to Bad Diode • • •I want you to go full on 😀 work in main. I'm planning to go full time on oquonie playdate when we return from stange loop(october-ish) in the meantime, if you wanna try and see how we can make it fast, it'd be awesome.
If you make big changes that could also improve sdl/x11 implementation, let me know. I try to keep all the different device implementations in sync if I can.
Bad Diode
in reply to Devine Lu Linvega • • •Bad Diode
in reply to Bad Diode • • •Run into a bit of an issue. I can compile ARMASM and link it into the elf file, so technically it would run on hardware. HOWEVER, the way that the simulator works is that it compiles the C code into a native .so file in the host architecture (in my case x86_64) using gcc, so my ARM assembly can't compile for the simulator.
I guess that's why it's called a simulator instead of an emulator.
For this reason I can't really test the assembly implementation 🙁
Any ideas?
#playdate
CC: @neauoire
Bad Diode
in reply to Bad Diode • • •Devine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •I could unroll this one and remove all conditionals: https://git.sr.ht/~rabbits/uxn/tree/main/item/src/uxn.c
I might try it out next month, I'll make 256 cases.
~rabbits/uxn: src/uxn.c - sourcehut git
git.sr.htBad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •Sigrid Solveig Haflínudóttir
in reply to Devine Lu Linvega • • •Global Register Variables (Using the GNU Compiler Collection (GCC))
gcc.gnu.orgSigrid Solveig Haflínudóttir
in reply to Sigrid Solveig Haflínudóttir • • •0/10 do not recommend.
Bad Diode
in reply to Sigrid Solveig Haflínudóttir • • •Sigrid Solveig Haflínudóttir
in reply to Bad Diode • • •Bad Diode
in reply to Sigrid Solveig Haflínudóttir • • •Bad Diode
in reply to Bad Diode • • •Got an initial fast (?) uxn-core in C for the playdate.
Need to do some testing still, but so far the testing rom, fibonacci and fizzbuzz seem to work. I probably should clean this up but there is some charm to this nightmarish code lol.
The eval function is just 267 LOC long!
The eval function:
Devine Lu Linvega
in reply to Bad Diode • • •https://git.sr.ht/~rabbits/uxn/tree/main/item/src/uxn.c#L36
~rabbits/uxn: src/uxn.c - sourcehut git
git.sr.htBad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •hahaha, that has some strong bathtub catapult energy.
"Like, if you build a catapult strong enough that it can hurl a bathtub with someone crouching inside it from London to New York, it will feel very fast both on take-off and landing, and probably during the ride, too, while a comfortable seat in business class on a transatlantic airliner would probably take less time but you would not feel the speed nearly as much."
- Erik Naggum
Devine Lu Linvega
in reply to Devine Lu Linvega • • •I'm going to have to type-check oquonie I guess ;) To make sure that it cannot possibly overflow.
https://git.sr.ht/~rabbits/uxnbal/
~rabbits/uxnbal - Uxntal validator, written in Tal - sourcehut git
git.sr.htBad Diode
in reply to Devine Lu Linvega • • •I mean... if you are releasing a program, what difference does it make if it tells you "error: i crashed because over/underflow" or that just crashes? The result is the same in both cases.
Furthermore, we just need to make programs that don't crash at all :3
Devine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •I never considered this but, maybe you're onto something.. stacks could loop around(it's a bit nicer than a hard crash), and push validation to the assembler so you always have predictable arity, making bound checking obsolete?
uxn agda core when
Bad Diode
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to Bad Diode • • •Bad Diode
in reply to Bad Diode • • •Devine Lu Linvega
in reply to Bad Diode • • •max22-
in reply to Devine Lu Linvega • • •Devine Lu Linvega
in reply to max22- • • •max22-
in reply to Devine Lu Linvega • • •https://groups.google.com/g/comp.lang.forth/c/qEndNz42bw0
"After twenty years of looking for a solution he said he
was very pleased to find one. He decided to make the
stacks circular. Stacks cannot overflow or underflow,
the wrap. He said, "Problem solved once and for all."
(he = Chick Moore)
that's just what @bd said ^^
About checking stack-underflow/overflow in FORTH
groups.google.comDevine Lu Linvega reshared this.
Devine Lu Linvega
in reply to max22- • • •Bad Diode
in reply to Devine Lu Linvega • • •I'm just more inclined to keep it as it is and just don't under/overflow
I took a brief look at this one and looks interesting: https://binji.github.io/posts/webassembly-type-checking/
WebAssembly type-checking
binji.github.ioDevine Lu Linvega
in reply to Bad Diode • • •https://wiki.xxiivv.com/site/uxntal_types.html
XXIIVV — uxntal types
wiki.xxiivv.comDevine Lu Linvega
in reply to max22- • • •Devine Lu Linvega
in reply to max22- • • •I really really like this actually.. The more I think about this, the more I like it.
The system device has system/wst DEI that one can use to check for the stack state when needed, so people can write their own error handling and checking if when and where they need. It might not need to be done at every step after all..
Bad Diode
in reply to Devine Lu Linvega • • •I like it! I still think error handling is best done during development either way. Oh one change I've been doing on my dei functions is have them return u16 instead of u8. From the assembly perspective, these are equivalent, and makes it so that you don't have to call the dei functions twice to get 16bit values:
typedef u16 (*DeiFunc)(u8 *dev, u8 port);
typedef void (*DeoFunc)(u8 *dev, u8 port);