• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Religious billboards

My favorite graffitti directed at a church....there is a stretch of I-95 South (going toward Northern Virginia) near Bethesda, MD (just outside DC), where you can see the Washington area's main Mormon Temple...a big, white marble castle-fortress like monstrosity. When I first moved to the area, on an overpass near the temple (you could see the temple looming just above the overpass) were painted the words "Free Dorthy"

Loved it! :D
 
Highway 99, in California between Bakersfield and Sacramento are quite a lot of these signs - of various flavors.

- Abortion stops a beating heart
- Something about how abortion is dangerous to the mother. (don't recall what, exactly)
- God's Billboards (Ready or Not, here I come! - God)
- Paintings of the Virgin Mary or the Virgin of Guadalupe
- large chunks of cardboard with raggedly ripped corners and blood red lettering sloppily painted on and nailed to telephone poles that say, "Jesus is coming!" "God Hates sinners!"

I really should take a digital camera on a road trip some time.
 
Upchurch said:
No, let me get right on that:

var JESUS = 'LORD' + 'SAVIOUR';

Whew.
Click to expand...

#include < stdio.h >
#define LORD 0x01
#define SAVIOR 0x02
#define JESUS (LORD & SAVIOR)

int main(void)
{
printf( "Jesus = %d\n", JESUS );
return 0;
}

Output:
Jesus = 0

Hmm... didn't amount to much.
 
There seems to be a lot more of that in the states. I don't see much religious craziness here.

Granted, it does make driving down there a lot more fun.

It seems to me that the religious people that make me most want to emulate them (ie. certain buddhists, quakers, etc), have no advertisement save for their actions. Makes me wonder why the Xian fundies must resort to billboards.
 
Riddick said:
write it in assembler, then you'll have my respect.
Click to expand...

Pardon the syntax: it's been a very, very long time since I've bothered with more than trivial inline assembly. Generally, NOT using C (or an even higher-level language) for this sort of thing is a fool's game.
Code: 
LORD equ 0x01
SAVIOR equ 0x02
JESUS equ (LORD & SAVIOR)

; Jesus = 0
_JStr:
   db 13,10,"Jesus = "
_nStr:
   db '0',13,10,0

_main:
; Add value of 'JESUS' to numeric zero in string
   add [_nStr], JESUS  
; Ask DOS to print it
   mov ah, 9
   mov dx,offset _JStr
   int 21h
   ret
 
Riddick said:
write it in assembler, then you'll have my respect.
Click to expand...

Well, you didn't specify CISC or RISC. I prefer RISC. I'll use the Microchip PIC as my processor.

Lets see:
JESUS.ASM

Hmmm
Somethings wrong with it
It keeps telling me that I'm going to hell.

Maybe it's because I re-used old code to suite my purpose - but I figured Jesus wouldn't mind since Christianity has done something similar.

:D
 
I just want to know who's writing "Trust Jesus" on all the bridges on interstates in this country. Did Jesus support vandalism?
 
Irony: Would you trust a bridge design that was based on "biblical authority"?


Anyway, as you can see, assembly code can turn the most trivial of one-off tools into a major project.

For instance, in a command shell, you might just write a script/batch to do something as trivial as echoing some text.

echo Jesus hates you.

Of course, for obfuscation purposes, there's nothing like the hundreds of lines of code with misleading comments along with the idiosyncratic syntax that even trivial assembly code can offer.

There are perfectly good back-ends to gcc for most microcontrollers, and techniques for using C (even C++) that will allow embedding more maintainable code, that while not *quite* as fast and/or small as native ASM and hand-tuning could possibly make something, will do an adequate job. Especially considering the extra investment in time and lack of portability of ASM code.

ASM: What, you wanted to use a different controller? OK, we just need to rewrite all the libraries and code from scratch just to get started... and oh yeah, this one's assembler uses a different syntax....

C: Let's just change the bits of code that manipulated registers and touch up incompatible library and application behaviors.

As a matter of fact, for PC development, almost every time I have encountered non-trivial ASM code with a problem, I've rewritten a better version in C to replace it, and it was faster, and smaller. The problem is that people will turn to assembly like it's a magical wand instead of composing (or looking up) a better algorithm. I've literally seen bubble sorts written in (no, obfuscated with) assembly code that I've replaced with the standard C runtime qsort for enormous improvements in performance.

In short, I'm not impressed by ASM code. Rarely have I encountered GOOD ASM code. Usually I encounter bad code design with even worse ASM code, like stripes painted down the side of a Geo Metro to make it "look faster". In one case, there was an INSTALL program written entirely in assembly code. Presumably so it could wait for all of that disk I/O as fast as possible. You don't want to wait a whole microsecond when it could've begun the next read (with built-in 90ms seek) in HALF a microsecond!

Generally, if I am to resort to assembly (incredibly rare, for brute-force, frequently called things that have an absolute need for every available clock) I write the C version first, and KEEP IT, #ifdef'd out. Then I write inline asm code in the affirmative half of an #ifdef directive, in the same function body. It does the job, helps document the intended function, keeps the interface clear (and allows the compiler to generate appropriate calling/return glue for me), and leaves the path to porting the code to another platform clear and easy. It also provides a nice prototype to write the ASM based on, and a handy way to play "what if" when I suspect there's a bug.
 
evildave said:

In short, I'm not impressed by ASM code. Rarely have I encountered GOOD ASM code.
Click to expand...

Agreed. My own code included.

It is just too difficult to write 300 lines of assembly for something you know you could easily do with 10 or 20 lines of C. So every ASM programmer creates a library of his favorite code snippets, and then reuses it as needed, stiched together with new code. After a while you get Frankenstein's monster. But at least it shambles along correctly and is done on schedule.

The problem in my industry is that we rely a lot on these little 8 bit microcontrollers to act as duct tape in a circuit. A lot of things in my job are accomplished real time, where nanoseconds matter. I'm stuck with ASM because I need to know to the nearest hundred nanoseconds when it will execute.

My preference would be to program with a soldering iron. :D

(edited to change timescale just a bit)
 
os/90:

DCLJCS START 0
SAVE (14,12)
BALR 10,0
USING *,10
BEGIN ST 13,SAVEAREA+4
LA 13,SAVEAREA
L 13,SAVEAREA+4
RETURN (14,12),,RC=0
JESUS DC C'JESUS'
SAVIOR DC C'SAVIOR'
SAVEAREA DS 9D
END
 
I subscribe to the bureaucracy theory to explain such billboards.

A pastor collects money from his congregation. Like a government bureaucracy, the pastor must be seen as doing something useful to justify his position and the donations he receives, so he buys billboard space with some slogan he knows will give his flock a religious woody.
 
calladus said:


Agreed. My own code included.

It is just too difficult to write 300 lines of assembly for something you know you could easily do with 10 or 20 lines of C. So every ASM programmer creates a library of his favorite code snippets, and then reuses it as needed, stiched together with new code. After a while you get Frankenstein's monster. But at least it shambles along correctly and is done on schedule.

The problem in my industry is that we rely a lot on these little 8 bit microcontrollers to act as duct tape in a circuit. A lot of things in my job are accomplished real time, where nanoseconds matter. I'm stuck with ASM because I need to know to the nearest hundred nanoseconds when it will execute.

My preference would be to program with a soldering iron. :D

(edited to change timescale just a bit)
Click to expand...

I'll admit, I've never seen compiler that made "nice" 8-bit code. Of course most 8-bit CPUs don't have requirements like cache management and instruction scheduling, either.

Actually, the Gameboy Color has a 'z80-like' instruction set (i.e., like a z80, but crippled) and a slow CPU, at that. I have always found C is an excellent tool for prototyping ASM work, being barely a step above it. Sure enough, someone had made a C compiler for it. It made some scary, awful looking output, but it ran.

You can get the big, seldom called things built in C rapidly, and even get the often called, critical things at least prototyped in it. The ASM version of the output is usually very available. Then it's just a matter of going into the spots where it mattered and cleaning up the mess.

Of course, other silly things like building DMA lists to look like call a stack, so you could set SP and "return" to "call" a sequence of things by getting the 'return from subroutine' behavior to invoke each next thing it needed to do had to be written, as did all the palette swapping during horizontal blank where we had very few cycles to do a lot of work before the CPU would be locked out of video memory again.

That's among the USUAL sort of work I used to do. In the 8-bit days, I actually knew the opcodes better than the equivalent assembler syntax for the 6502 in Apple, Commodore, Atari and my Ohio Scientific computer. Later with the Atari ST, I realised that the C compiler was doing a much better job for the amount of effort I put into things. Without the hard-core C, a lot of the later work I did on PC (DOS, Win16, Win32, Unix/Linux), N64, Playstation, Gameboy, Palm, etc. (Just call me "Jack") would've been a lot more time consuming. Especially when it came to re-using snippets. I've had to make games work in a lot of these. Palm OS was definitely the worst for getting graphics on the screen.
 
evildave said:


I'll admit, I've never seen compiler that made "nice" 8-bit code. Of course most 8-bit CPUs don't have requirements like cache management and instruction scheduling, either.

Actually, the Gameboy Color has a 'z80-like' instruction set (i.e., like a z80, but crippled) and a slow CPU, at that. I have always found C is an excellent tool for prototyping ASM work, being barely a step above it. Sure enough, someone had made a C compiler for it. It made some scary, awful looking output, but it ran.

You can get the big, seldom called things built in C rapidly, and even get the often called, critical things at least prototyped in it. The ASM version of the output is usually very available. Then it's just a matter of going into the spots where it mattered and cleaning up the mess.

Of course, other silly things like building DMA lists to look like call a stack, so you could set SP and "return" to "call" a sequence of things by getting the 'return from subroutine' behavior to invoke each next thing it needed to do had to be written, as did all the palette swapping during horizontal blank where we had very few cycles to do a lot of work before the CPU would be locked out of video memory again.

That's among the USUAL sort of work I used to do. In the 8-bit days, I actually knew the opcodes better than the equivalent assembler syntax for the 6502 in Apple, Commodore, Atari and my Ohio Scientific computer. Later with the Atari ST, I realised that the C compiler was doing a much better job for the amount of effort I put into things. Without the hard-core C, a lot of the later work I did on PC (DOS, Win16, Win32, Unix/Linux), N64, Playstation, Gameboy, Palm, etc. (Just call me "Jack") would've been a lot more time consuming. Especially when it came to re-using snippets. I've had to make games work in a lot of these. Palm OS was definitely the worst for getting graphics on the screen.
Click to expand...

Ah! A kindred soul! (if we have souls - which I doubt, but I'll let it stand as prose.)

I haven't done any work in games, or in game platforms. My background is in communications and in motion control. Plus I'm mostly hardware. I can program, but I can't create 'art' as some programmers do - not enough practice in it I guess.

I would love to discuss gaming software with you, especially because I love the idea of hacking a gameboy to make it do odd things. But I think we've derailed this thread enough. We should move somewhere more agreeable to this sort of discussion.

This is all Upchurch's fault! heh heh heh.

:D
 
Ha! Leave it derailed! I laugh at the topic police! Ha-ha-ha... (scuffling sound)

Actually, there are a lot of gameboy resources out there. GOOD software emulators, with debuggers, too. You can still find EEPROM carts for the gameboy as well.

Of course, for a little more scratch, get yourself an Gameboy Advance and the same kinds of tools are available for that, too. But you get a flat memory model and a proper CPU with lots of spare cycles.

http://www.work.de/nocash/index.htm

No$GMB was absolutely vital when we used it. The tools Nintendo provided were utter garbage compared to it.

There is a No$GBA, too. Of course, this guy wants money for it.
 
At a bus stop: Poster of bearded man with text "Where will you be on judgement day?". Below in handwriting: "Probably still waiting for the bloody bus"
 
You must log in or register to reply here.

Back
Top Bottom