Gameboy Development Forum

Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)

You are not logged in.

Ads



Poll: Your rating (5=best)

1: 0 votes
0%

2: 1 votes
9%

3: 3 votes
27%

4: 3 votes
27%

5: 4 votes
36%


Total voters: 11

#1 2014-07-09 19:58:58

Sanqui
Moderator
Registered: 2013-01-04
Posts: 20

[2014] Bleep (Andy)

Download: http://gbdev.gg8.se/files/gbdev2014/Bleep/bleep.gb
Example song: http://gbdev.gg8.se/files/gbdev2014/Bleep/bleep.sav
Readme: http://gbdev.gg8.se/files/gbdev2014/Bleep/

Or download a zip containing all ROMs: http://gbdev.gg8.se/files/gbdev2014/gbd … llroms.zip

==========================

Bleep
Game Boy Dev Compo Version
(prerelease / alpha)
by Andrew G. Crowell

Bleep is a music creation program with piano roll interface.

It lets you jam out chip music really quickly, and it writes directly into save
memory, so your work is saved automatically. This is not the final version, but
I was reminded the Game Boy dev compo was going on, so I'd enter.

This is just a prerelease, the final will include source code, and add many
missing features to the editor.


http://gbdev.gg8.se/files/gbdev2014/Bleep/screen1.png

Last edited by Sanqui (2014-07-09 20:07:03)

Offline

 

#2 2014-07-29 20:46:53

a cat
Member
Registered: 2014-07-27
Posts: 98

Re: [2014] Bleep (Andy)

do you have the source?
please tell me how you made a .sav file?


a cat in need of knowledge!!

Offline

 

#3 2014-07-30 12:14:29

Overkill
New member
Registered: 2013-05-27
Posts: 3

Re: [2014] Bleep (Andy)

Hi, I'm the author of Bleep. I can't provide the source (yet). I will release the source to Bleep when I finish it. But until then, I can tell you that it's written in a high-level assembly language that maps almost 1:1 to the GBZ80 instruction set, you can reverse engineer the source code using a disassembler to get a rough idea of the original, just know that there are a lot of things that I intend to change, so this is why it's not public yet.

In the meantime, I can explain how to persist things to save RAM.

It depends largely on your cartridge's MBC type. I use MBC5: http://gbdev.gg8.se/wiki/articles/MBC5

Here's a summary of save management for MBC5 (the other MBCs work similarly, but read their documentation to be sure):

- Select an 8K bank of save RAM to view by writing $0 - $F into $4000.
- The bank you selected will be visible in 8K memory area from $A000 - $BFFF.
- Enable save RAM access by writing $0A to $0000. When enabled, you can read/write to $A000 - $BFFF.
- Disable save RAM access by writing $00 to $0000.

The first time you use save RAM, it will be uninitialized. Some emulators will fill this with zeroes, but good emulators like BGB will fill this area with random noise (or in the case of single-ROM dev carts, might be the save data of another ROM). To ensure your save is initialized, and not just garbage memory, you need to write a signature of some kind into the RAM. This signature could be a simple 2-3 byte sequence, like a short piece of text or numbers. If this signature isn't there, you should initialize your save RAM (possibly by clearing it, maybe doing more) and then add the signature.

Some stuff will improve their save format and also add simple checksum or parity fields. This can be useful for detecting corrupted saves, by verifying that the checksum/parity of the bytes in the save match the value in the checksum fields. This helps integrity check saves are written correctly, and for games, might be useful to prevent undesirable states from being reached. Bleep doesn't do this (but might do some limited validation -> correction in spots), because for a song editor, a corrupted song is slightly better than completely losing a song, and can be fixed.

Last edited by Overkill (2014-08-04 18:58:32)

Offline

 

#4 2014-08-12 08:53:59

a cat
Member
Registered: 2014-07-27
Posts: 98

Re: [2014] Bleep (Andy)

can you do this in c
or do you have to use z80 assembly?


a cat in need of knowledge!!

Offline

 

#5 2014-08-12 18:57:16

Overkill
New member
Registered: 2013-05-27
Posts: 3

Re: [2014] Bleep (Andy)

I only use assembly, so I unfortunately am not familiar with how GBDK handles that.  GBDK must handle bank-switching for ROM code bigger than 32K, but my guess for variables is it would only use the 8K of system RAM and not touch the cartridge RAM. You can definitely write to the SRAM in C, but you may need to do it a bit manually.

Methods in order of niceness:
1) Use GBDK's library functions or macros.
2) Create a pointer to the memory-mapped registers explained in the docs for your specific cartridge MBC. So, like, create a volatile uint8_t* / volatile unsigned char* pointing at the memory locations (SRAM area + the bank switch registers) you want to address and then write values into it.
3) Alternatively, some helper functions with inline assembly could write to the MBC RAM bank registers. Then once RAM is enabled and the correct bank is selected, you can have a volatile pointer that will be used to write a bunch of junk into SRAM.

That hopefully should be enough to by.

Last edited by Overkill (2014-08-12 19:03:14)

Offline

 

#6 2015-04-13 21:16:11

npzman
Member
Registered: 2014-11-19
Posts: 143
Website

Re: [2014] Bleep (Andy)

When will the final version get completed

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson