itch.io

I've made some optimizations to how the Grid & Sprite layers are rendered in the latest updated: https://negative11.itch.io/frem-sprite32/devlog/444743/making-some-optimizations.... This should result in some reduction of memory overhead and CPU load when not working with these layers. Other recent updates also provide more options for window resolutions and resizing that could also make a difference. 

Thanks for checking it out and for the feedback!

There are likely some opportunities to optimize the way I'm rendering the Grid, Pixel, and Sprite layers, especially when they are not in use. Under the hood there are a lot of objects on the canvas that are making that stuff work, which is probably increasing the cpu/gpu load. I'll do some more testing on mac this week and see if there are some things I can unload when not in use.

For capturing that text input away from the editor, check out chapter 15 in the manual. If you're already getting text input, you're pretty close, there's just one more line you'll need.

Cheers, and happy coding!

-- John

I definitely want to incorporate the concepts from other projects based on SAP architecture and 8080 Assembly into future development, e.g. https://github.com/johnsquibb/Go-SAP and https://negative11.itch.io/sap-1-emulator. I don't have any roadmap of what that looks like just yet, but it's definitely on the want-to-do list.

Thanks for checking it out! Exportable binaries is an interesting idea. Right now, FREMScript is tokenized, parsed, and evaluated on the fly using the underlying Godot game engine and its native GDScript language. So, in that sense, the machine code is really just a bunch of GDScript objects. I suppose if we think of the Sprite32! as a Virtual Machine for FREMScript, then to support exporting complete projects, there would need to be some low level "bytecode" representation, possibly serialized exports of the GDScript objects that could be deserialized and run by any Sprite32! system later. I like this approach, and early builds had the notion of ROM cartridges that could be loaded from files. Those early versions were just FREMScript saved to a file with .rom extension, and since this wasn't unique to other files saved with .frem extension, I ultimately simplified it down to just the latter file format.

Another approach, and possibly the one you may be thinking, would to be support complete executables that could be run standalone from the game itself, probably everything presented in the screen area. That approach is likely out of scope for this project, but I think it could be done by generating the equivalent GDScript code from a FREMScript program and putting that through the Godot build tools to generate a full executable.

A third idea comes to mind as I write this response and is a mix of the two previous ideas: a FREMScript runner VM application that is just the screen and input support, with all the extraneous game elements removed. Exported "bytecode" could be loaded into that virtual machine and run. The VM could open source/free and distributed with binaries that users of the Sprite32! write. I kind of like this idea, and thematically it fits into the FREM corporation's roadmap of releasing a consumer game console system based on a stripped down version of the Sprite32! I could definitely see them presenting that at COMDEX '87.

I'll definitely add a sticky to the dev board and noodle this some more for future versions of the project. Thanks for the feedback!

About a year ago, I put together a visual emulator based on the Simple-As-Possible architecture, tossed it on GitHub, and kind of forgot about it. While digging through some old projects, I came across it and decided to upload it here!

Download it here: https://negative11.itch.io/sap-1-emulator

What can you do with it?

• Enter Assembly instructions and manipulate memory values by entering instructions on the keypad interface. 
• Run simple programs to add, subtract, and display results. 
• Step through programs to watch how the registers behave at each step.
• Save/Load programs 1-4, externally edit source and RAM files in the src directory and run them in the game.

Hi!

Yesterday I released  a simulator/sandbox/programming/retro-computer-y thing I've been working on, called: FREM Sprite32! Right now, you can play around in sandbox mode and learn all about the language that powers the machine: FREMScript.

Get it here: https://negative11.itch.io/frem-sprite32

Current Features

• Write programs using the high-level FREMScript interpreted programming language
• Read the in-game manual to learn the language, discover system settings, and copy code examples to run in the editor.
• Display text and get keyboard input from the user as the program runs.
• Get feedback in the status window for current system state, including program errors and highlighting.
• Play with sprites, pixels, the color grid, and 3-channel waveform audio generation.
• Save and load files, even swap out the default boot program with your own!

Check out the Devlog for more about features, plans for the future, etc.

There is also a GitHub repository with numerous examples to get you started.  For instance, I've been working on a simple little single player pong-like game this morning:

Cheers!