Talk:BytePusher

Announcements

 * I have implemented the BytePusher VM. http://zzo38computer.cjb.net/prog/BytePusher/ --Zzo38 03:12, 3 September 2010 (UTC)
 * Version 0.2 now implements audio (I don't know if it is properly synchronized). I also added the BytePusher logo to the table of contents page. --Zzo38 01:23, 17 October 2010 (UTC)


 * Currently implementing reconfigurable keys in my VM (something similar to Zzo38's implementation). --Javamannen 11:54, 6 September 2010 (UTC)
 * Done! --Javamannen 08:25, 8 September 2010 (UTC)
 * Changed the audio implementation of my VM to use 8 audio buffers (2048 samples). Hopefully this will make the audio run smoother on some platforms, like FreeBSD. --Javamannen 00:16, 18 October 2010 (UTC)
 * Wrote a program. It shows a scroller alongside a simple effect(adding 1 to the colour value), then acts like an etch-a-sketch. https://dl.dropboxusercontent.com/u/21184720/donotdelete_bp.BytePusher --gamemanj 10:50, 6 January 2015

The audio spec
About this whole mu-law business... It seemed like a good idea, but now I'm having second thoughts. Does it add too much complexity for the reward of slightly better sound quality? I mean, simplicity and directness were the key design goals for this thing. And mu-law isn't all that intuitive. And I guess standard linear 8-bit sound is "good enough" for simple games'n'stuff. Also, I kinda like that whole lo-fi chipmusic aesthetic. So... I'm leaning towards going back to the way it was. But I'd like to get a second opinion first, if anyone is reading this... --Javamannen (unsigned)
 * I think raw audio is fine; mu-law probably decreases quality slightly on music, rather than speech. 91.105.124.106 00:06, 4 September 2010 (UTC)


 * I agree, raw audio is fine, and fits better with the simplicity and directness. BytePusher is not intended for speech, anyways (μ-law is intended for speech). --Zzo38 01:46, 4 September 2010 (UTC)


 * Alright, it's settled then. I'll revert the spec back to raw 8-bit, and change the audio part of my VM. Then I'll see if I can make a simple audio test program, as an aid for VM implementers. --Javamannen 05:25, 4 September 2010 (UTC)


 * Done! --Javamannen 11:54, 6 September 2010 (UTC)

Comment on first specification page
Calling the BytePusher a 3.93 Mhz machine from what can be read on the specification page seem a little rushed to me.. I can follow that it should be ~3.93 MIPS from the fact that the machine executes that many instructions per second, but the MHz is normally not directly coupled to this. In the case of this VM executing each single instruction in 1 clock cycle, then this would lead to 3.93 MHz <=> 3.93 MIPS. The one thing actually missing as I see it, is the execution time/Length for each instruction measured in clock cycles.

overclocked (talk) 07:15, 9 August 2012 (UTC)

Video Authenticity
This looks like a nice authentic machine of that era (with a CPU that's a little odd) even the video sync being hooked into the NMI is a known video game trick to fake a watchdog timer. Ie if it doesn't make it to the idle loop the machine must have crashed and should be reset.

Except, the video just doesn't seem right. The most obvious thing is that it's the wrong shape; it should be 320x200 to give you 40x25 characters. These pixels were supposed to be square despite many people stretching their images to fix the 4x3 physical screen.

Another thing is the 'CLUT' it just would never be done to leave 40 colors unused. As I recall the old MACs used the 6x6x6 cube, to which they added four sixteen color ramps in red, green, blue and white.

Actually, I think something authentic would work like this:

64K of memory assigned to the display. The first 64000 bytes are the pixels in a 320x200 array, at the end are 768 bytes for a color lookup table defaulted to the old MAC map. Rdebath (talk) 14:14, 28 September 2013 (UTC)

Project ideas
Feel free to refine these, or add your own.

External Tools

 * Assemblers
 * PUSHEM

(Virtual) Machines

 * A VM that can run in a browser
 * Java
 * Google's Native Client?
 * A BytePusher browser plugin?
 * V8 JavaScript
 * Hardware implementation
 * FPGA
 * Standard logic ICs?

Applications

 * Some easily-implemented games
 * Pong clone - every platform should have one =)
 * Pacman / Maze type game


 * Some type of interactive BASIC editor like on early home computers
 * Tiny BASIC would probably be one of the easiest to do. Would have to devise some smart way to write code using only 16 keys.


 * BytePusher "OS"
 * Quickstart menu - one-key selection from up to 16 applications (name + icon for each app)
 * A basic hex editor (hand-coded in machine code in an external hex editor, just for the kick of it =) - the embryo of a self-hosted BytePusher IDE =)
 * I've implemented such a Hex editor for Chip-8 that works quite well. With the right tools I could probably implement it here too. -User:overclocked-2011-09-11 10:30 UTC
 * Some kind of minimal hardcoded kernel / BIOS. Routines like: memcopy, memset, text output (using a fixed-width system font), blitting. Some useful opcode tables (add/subtract with carry/borrow, logical AND/OR/XOR, int->bool, ternary selection for conditional jumps etc.
 * Some kind of crazy system for runtime generation of various opcode tables to facilitate a virtual dynamically reconfigurable instruction set =)

Networking?
I just wanted to start by saying that this is a very interesting VM. BytePusher and its very simple instruction setup, plus the graphics and sound support make it a esoteric project worth developing on. I want to suggest some networking support for this VM, because with that you could connect to other computers (obviously), and make some multiplayer games or download extra code that could be run on the CPU, thus expanding possible memory limitations. I understand that this is probably a very big thing for implementation to support, due to all the specifications already created (TCP sockets, website connection, etc.), so I propose this: how about only being able to connect to other BytePusher computers? That way, you're able to develop multiplayer games that would run above an implementation with the BytePusher's networking requirements, which could be anything, really. This way, you can keep it simple. Xav737 (talk) 18:05, 15 August 2017 (UTC)